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TITLE: Region-wide messaging system and methods including validation of transactions 



Abstract Text (1) : 

Methods and systems are disclosed that allow for the exchange of voice mail messages between 
different VMSs of different service providers and/or in different networks by the transmission 
of such messages through a data network using a standard protocol of the data network. Methods 
and systems also are disclosed that validate message transactions among subscribers receiving 
regional messaging services over the PSTN. The subscribers are located in different geographic 
areas and may be provided their voice, facsimile or data messaging services by different 
companies. The present invention validates passing messages (data) among customers of 
potentially different companies located in different areas by assessing the validity of the 
transaction in light of a number of conditions, including applicable regulatory or business 
conditions. 



Brief Summary Text (4) : 

Telephone answering machines are used by many consumers to collect messages that are received 
while the consumers are unavailable. But such answering machines have limitations that pose 
inconveniences. For example, a conventional telephone answering machine generally will not take 
a message from a caller when the called party is already engaged in a call. The caller must 
call again even though the called party has an answering machine. Some of the limitations of 
telephone answering machines have been overcome by network voice mail services typically 
offered by telecommunications service providers. For example, generally, a network voice mail 
service will take a message from a caller when the called party is already engaged in a call. 

Brief Summary Text (5) : 

While telephone answering machines and network voice mail services are used by consumers in the 
home and in small businesses, other telecommunication products have been developed to serve 
larger businesses, and other institutions such as schools, hospitals, government offices, and 
the like. These other telecommunication products include telecommunications systems having 
advanced messaging features. These advanced messaging features typically provide a user with 
more options than a conventional telephone answering machine or network voice mail service. 

Brief Summary Text (9) : 

Considering the three types of products discussed ( telephone answering machines, network voice 
mail services, and telecommunications systems having advanced features), there are needs of 
users left unsatisfied by these products. For subscribers to network voice mail services, and 
especially for users of telephone answering machines, there is a need for an apparatus, system, 
or method that will provide the functionality of the telephone answering machines and the 
network voice mail services as well as provide the advanced messaging features of the 
telecommunications systems generally used in larger institutions. But it is not enough to 
satisfy the needs of users by providing telecommunications systems having advanced features to 
subscribers of network voice mail services and/or users of telephone answering machines. It is 
not satisfactory because the advanced messaging features of such systems are available only to 
persons associated with the institution having deployed the particular telecommunications 
system. Thus, there is a need for an apparatus, system, and/or method that provides a user with 
advanced messaging features and that may be used in connection with communications to other 
users even if the other users are not associated with a common institution. In sum, there is a 
need for an apparatus, system, and/or method that implements a messaging system across a region 
for the exchange of communications between and among users of the region. 

Brief Summary Text (10) : 

Multiple obstacles exist to providing users with a region-wide and feature-rich messaging 
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system. The region-wide messaging system may include multiple service providers with each 
service provider having one or more voice mail platforms, etc. As a result, technical, 
regulatory, and business constraints may prevent the exchange of messages in the region-wide 
messaging system between users who reside in different states or areas of the region, and/or 
who are served by different service providers. For instance, in the United States, some state 
and/or federal regulations prevent certain categories of service providers from transferring 
telephone calls, and possibly messages, across state boundaries and/or across LATAs ("Local 
Access Transport Areas") . Also, even if users are in the same state or LATA, a user may choose 
to subscribe to messaging service from a service provider different from another user's service 
provider. Unless service providers have reciprocal business agreements for accepting each 
others 1 traffic within the region-wide messaging system, message exchange between the users may 
not be possible or may be possible only accompanied by a large toll charge. Similar regulatory 
restrictions and business considerations may apply in other countries and/or in messaging 
systems that operate across national borders and are included in a region-wide messaging 
system. 

Brief Summary Text (11) : 

Some of the obstacles posed to a region-wide messaging system by regulatory, technical, and 
business constraints can best be illustrated by an example. Assume two people (Oscar and 
Rachel) subscribe to voice mail service provided through a region-wide messaging system. Oscar 
lives in Louisiana. In Louisiana, BellSouth provides Oscar with local telephone service, and 
Oscar has chosen AT&T to provide voice mail service through the region-wide messaging system. 
Oscar wishes to originate or leave a message for Rachel, the message's recipient who lives in 
Georgia. In Georgia, BellSouth provides Rachel with local telephone service, and Rachel has 
chosen BellSouth to provide voice mail service. Oscar calls Rachel, who is unavailable, so 
Rachel's voice mail service plays a pre-recorded message and prompts Oscar for his message. 
Oscar leaves a message. Rachel eventually retrieves the message, but instead of actually 
talking with Oscar, Rachel would prefer to dash off a quick reply by using her voice mail 
service . 

Brief Summary Text (20) : 

This invention a region-wide messaging system that uses more than one messaging server ("MS"), 
such as a voice mail platform. Each MS may be located respectively in a different geographic 
region and operated by a different service provider. A caller initiates a message in a first MS 
to be delivered to a subscriber served by a second MS. The first MS queries a directory by 
forwarding at least the subscriber's telephone number. Using the telephone number of the 
recipient ( subscriber ) , as well as either the sender's phone number or information identifying 
the first MS that the first MS forwards to the directory, the directory applies various tables 
and rules to determine the service provider and location (by, e.g., LATA, state or other 
subdivision) for each of the sender and recipient. If regulations allow messaging transactions 
between those locations, and if the first and second MSs are operated by different service 
providers, then a determination is made as to whether one or more agreement (s) exist (s) between 
the different service providers that will allow the transaction to be validated and go forward. 
These determinations can, of course, also be carried out after the messaging transaction in 
order, for instance, to determine the billing rate for the particular messaging transaction. 

Brief Summary Text (21) : 

A region-wide messaging system may also allow subscribers to activate a message delivery 
service for the delivery of messages to a group of recipients, including subscribers and non- 
subscribers of service providers associated with the region-wide messaging system. A message to 
a subscriber is delivered only if the proposed transaction associated with the message is 
validated. A message to a non -subscriber need not be validated because such a message is 
delivered by a telephone call to the non -subscriber ' s voice mailbox, a function allowed under 
existing regulations. 

Brief Summary Text (22) : 

Whether replying, forwarding or distributing a message to one or more subscribers or non- 
subscribers, the destination address (e.g., telephone number) is collected. For a reply message 
to a non -subscriber, the non -subscriber 1 s address (e.g., telephone number) may be discerned by 
analyzing the calling line identification information provided by the telephone network when 
the non -subscriber leaves the original message. For a reply message to a subscriber, the 
subscriber's telephone number is collected from the originating address (e.g., telephone 
number) of the message left by the subscriber . 
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Brief Summary Text (23) : 

As noted, the destination telephone number as well as either the originating telephone number 
of MS identity are provided to the directory, which allows the present invention thereafter to 
determine whether business and regulatory rules allow the messaging transaction to go forward. 
Additionally, the destination telephone number allows a verification message to be provided to 
the user originating the transaction. The verification message alerts the user both to the 
validity of the transaction and to the identity of the message's recipient. For subscribers, 
the verification message may be formulated by using the destination telephone number to 
retrieve, via the directory, the subscriber's spoken name or other audio message; for non- 
subscribers , the verification message may simply be the telephone number. 

Brief Summary Text (24) : 

One type of region-wide messaging system with which the present invention may be used is 
deployed over a public switched telephone network (PSTN) that uses various Advanced Intelligent 
Network ( "AIN" ) components. For instance, commercially available voice mail platforms may be 
reconfigured as messaging servers and provided with appropriate AIN functionality so that the 
messaging servers act as an intelligent peripheral within the AIN. The messaging servers 
interface with another, directory server, such as Lightweight Directory Access Protocol 
("LDAP" ) directory servers available from various suppliers and which may be configured to hold 
the directory information. Or, Service Control Points ("SCPs") could be reconfigured with LDAP 
server functionality and adapted to hold the one or more directories and databases that are 
used with the present invention. In any event, each directory server may be equipped with a 
Regional Messaging Directory ("RMD") that indexes telephone numbers to identify the messaging 
server (MS) serving a particular telephone number or group of telephone numbers. One or more 
other tables in the directory may list: (a) the location of particular MSs, by LATA, state or 
other subdivision; (b) the rules governing message transactions among inter-state, inter-LATA 
or other inter-divisional MSs; (c) the business agreement rules governing the exchange of 
messages between service providers and others associated with the region-wide messaging system; 
and (d) certain flags that indicate whether messages may be sent to or from a particular 
subscriber based on a variety of criteria ranging from whether the subscriber has paid his 
bills to a subscriber's particular language. 

Brief Summary Text (25) : 

A preferred embodiment of a region-wide messaging system in which the present invention may be 
deployed uses a transmission control protocol/internet program (TCP/IP) network to allow 
transfer of messages among various MSs. Queries to and responses from the LDAP Server on which 
the RMD resides may be executed using internet protocols, such as the Lightweight Directory 
Access Protocol ("LDAP") that is a TCP/IP-based derivative of the X.500 electronic mail 
delivery service. Skilled persons will recognize that while a region-wide messaging system may 
use TCP/IP and LDAP protocols to query directories and other network elements, other protocols 
may be used, such as the signaling system 7 (SS7) . Indeed, SS7 protocol would allow 
implementers to take advantage of the reliability and known capability of an established 
telecommunications protocol. 

Brief Summary Text (26) : 

In another aspect of the invention, a region-wide messaging system is facilitated by allowing 
subscribers to reply to received messages by authenticating the reply recipient and the 
proposed reply transaction. The subscriber ' s MS queries the LDAP Server's RMD via messages in 
LDAP protocol that provide the RMD both the subscriber's telephone number and the reply 
recipient's telephone number. (As used herein, the telephone number is assumed to identify the 
voice mailbox, although other identifiers may be used) . The RMD determines the identity of each 
MS associated with the telephone numbers provided. Using a number of tables, the RMD ascertains 
the geographic location of each MS and whether regulatory rules allow a message transfer 
between MSs in those locations. Assuming a positive response, the RMD determines whether, if 
the MSs are operated by different service providers, those service providers' agreements allow 
exchange of messaging traffic. The RMD provides the subscriber ' s MS with this information, and 
the MS, in turn, authorizes or stops the proposed messaging transaction. 

Brief Summary Text (27): 

Optionally, the present invention may determine whether a reply message is possible before the 
subscriber attempts such a reply. For example, when a subscriber accesses the voice mail 
service for messages, a message is played to the subscriber . During message retrieval, the 
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subscriber ' s MS queries the RMD to determine whether a reply may be made to the message 
originator, using generally the same procedure as described above. After validation of a reply, 
the MS informs the subscriber that a reply may be made, perhaps through an announcement of 
"Would you like to reply to [spoken name of originator]?" 

Brief Summary Text (28) : 

Similarly, when a subscriber wishes to formulate a message for multiple recipients, the 
subscriber accesses the voice mail service, prepares the message and enters the list of 
destination telephone numbers. The subscriber ' s MS formulates an LDAP query that provides the 
LDAP Server with the telephone number (s) of the recipient (s) for the message, as well as the 
subscriber's telephone number. Upon receiving those numbers, the LDAP Server determines whether 
they are numbers of subscribers who have voice mail service through the region-wide message 
system. The LDAP Server then routes the numbers to the RMD. The RMD compares the numbers to an 
index and determines the identity of the serving MS for each number. Using other tables and 
indexes, the RMD determines the location of each MS, whether regulatory rules permit messaging 
transfers between the subscriber ' s (i.e., the message sender) MS and the recipient's MS, and 
whether, if the two MSs are operated by different service providers, business agreements 
between the service providers allow the recipient's MS to accept messages from the subscriber . 
That information is returned to the subscriber 1 s MS, which alerts the subscriber to any 
telephone numbers to which messages may not be delivered. For validated telephone numbers, the 
messaging transaction proceeds. 

Brief Summary Text (29) : 

Validation of messaging transactions may be adapted to particular situations. For instance, if 
the region-wide messaging system is deployed in multiple countries, only some of which allow 
international messaging transactions, the present invention can be adapted to validate those 
transactions also. Further, it is anticipated that the validation criteria may be modified or 
changed as regulations from regulatory bodies and agreements among service providers change. 
Indeed, the examples above are only a few of the ways in which proposed message transactions 
may be validated. Other validation criteria may be selected. For instance, the directory may 
indicate a subscriber has paid his or her bills and can proceed with messaging transactions 
(e.g., if the subscriber has not paid the system may reject the message. Another important 
billing feature may be to alert the user to whether the message will incur an additional fee, 
for instance because the message exceeds the number of messages purchased by the user for that 
particular billing cycle. Or, the directory may indicate the sender's and receiver's spoken 
language or other shared features, which the present can compare. Another important criteria on 
which to validate the message transaction may be to determine whether the user has paid his 
bill or is otherwise authorized to use the messaging service. These and other validation 
criteria may be added to the directory. Thereafter, the present invention validates the 
transaction based on the new or added validation criteria. 

Brief Summary Text (30) : 

Although the embodiment described above and elsewhere in this document describes deploying the 
directory upon an LDAP Server, persons skilled in this field will recognize that other 
platforms can be used to perform that functionality. For instance, the directory can be 
integrated into a workstation that in turn can couple to the public switch telephone network 
("PSTN"). Additionally, the present invention can be adapted for use with IP addresses instead 
of telephone numbers. 

Brief Summary Text (32) : 

To provide a method or system for providing messaging subscribers a convenient and reliable way 
of exchanging information with other users of the region, whether or not the other users are 
subscribers associated with the region-wide messaging system. 

Brief Summary Text (39) : 

To provide a method or system capable of either blocking messaging services for or to certain 
subscribers or billing certain subscribers for particular messaging transactions. 

Detailed Description Text (5) : 

Caller: A caller is a participant in a messaging transaction who has placed a telephone call 
that may result in a message to a subscriber of a region-wide messaging system. A caller may 
also subscribe to the region-wide messaging system, offered either through the same service 
provider as that of the subscriber or through another service provider. 
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Detailed Description Text ( 9 ) : 

Subscriber : A subscriber is a person or entity who receives the benefit of services offered by 
service providers participating in a region-wide messaging system. The subscriber need not 
necessarily be the person who actually pays for the services. 

Detailed Description Text (10): 

Transaction: A transaction is the transfer of a message from one originating device or 
messaging server (MS) to a destination device such as a telephone or computer or another MS, 
which may be a different or same type of MS, located in a different or the same region, or 
operated by a different or the same service provider. The message may be a reply message, a 
message formulated to go to one or more recipients, a forwarded message (whether fax, another 
voice mail, video or data), or any other type of message transmitted among the MSs of the 
region-wide messaging system and intended for review by a desired recipient. 

Detailed Description Text (12) : 

Messaging Server: A messaging server (MS) is a platform, including both hardware and software, 
from which voice mail and other messages and other services involving message transfer, reply, 
forwarding, etc. are provided to subscribers . The inventions described herein are not 
restricted to a particular embodiment of voice mail or other messaging server since it is fully 
intended that different types of voice mail or messaging servers, perhaps operated by 
respectively different service providers, may be used within and without a region-wide 
messaging system for messaging transactions. 

Detailed Description Text (15) : 

The RWM system described herein may allow a subscriber to the messaging system within the 
region of the service provider to send, receive, forward, and reply to messages, including 
voice mail messages and Voice Profile for Internet Mail (VPIM) Messages. Subscribers may 
receive messages from other subscribers and non -subscribers . Subscriber -to -subscriber 
messaging, however, illustrates the advanced features of the RWM system, which may be 
available, such as: (1) each subscriber may send a message to another subscriber ; (2) each 
subscriber may reply to a message received from another subscriber ; (3) each subscriber may 
reply to a telephone message received from a non -subscriber by implementing a feature that 
dials the non -subscriber ; and (4) each subscriber may receive and reply to internet voice 
messages or fax messages. 

Detailed Description Text (17) : 

FIG. 1 is a block diagram of an exemplary RWM system 10 (also referred to as a 
telecommunications messaging network) . The network 10 includes a variety of interconnected 
network elements. A group of such elements includes the plurality of end offices which are 
indicated as service switching points (SSPs or switches) 12a, 12b, 12c. An SSP typically 
includes switch functionality, but also includes other functionality so as to communicate with 
other network elements, and in particular, with Advanced Intelligent Network (AIN) elements. 
SSP 12a and SSP 12c are each coupled to a subscriber line, which also may be referred to as a 
line or a calling line. Each SSP 12a, 12b, 12c serves a designated group of lines, and thus, 
the SSP that serves a particular line may be referred to as its serving switch. The line is 
typically connected to a piece of terminating equipment including telephones 14, 38. Although 
telephones 14, 38 are illustrated as the terminating equipment, those skilled in the art will 
understand that such terminating equipment may include other telecommunications devices 
including, but not limited to, facsimile machines, computers, modems, etc. End offices may 
further be coupled through a tandem office (not illustrated) , which may be used to connect and 
switch circuits between and among end offices. 

Detailed Description Text (18) : 

Each active line in an AIN is assigned a ten digit (NPA-NXX-XXXX) line number regardless of 
whether seven or ten digits are dialed to reach the subscriber . A line number is commonly 
referred to as a telephone number or a directory number. 

Detailed Description Text (20) : 

SSPs 12a, 12b, 12c are interconnected by a plurality of trunk circuits 18. These are the voice 
path trunks that connect the SSPs to connect communications. In addition to connections to 
other elements, each of the SSPs is connected to a local signal transfer point (STP) 20 via 
respective data links. Currently, these data links employ a signaling protocol referred to as 
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Signaling System 7 (SS7) . Much of the intelligence of the AIN resides in a service control 
point (SCP) 22 that is connected to STP 20 over an SS7 data link. Among the functions performed 
by the SCP 22 is the maintenance of network databases and subscriber databases as represented 
collectively by databases ( subscriber data) 24. 

Detailed Description Text (21) : 

In order to keep the processing of data and calls as simple as possible, a relatively small set 
of triggers is defined at the SSPs for each call. A trigger in the AIN is an event associated 
with a particular call that generates a packet to be sent to an SCP. The SCP queries its 
databases or service package applications (SPAs) for processing instructions with respect to 
the particular call. The results are sent back to the SSP in a response from the SCP 22 through 
STP 20. The return packet includes instructions to the SSP as to how to process the call. The 
instructions may be to take some special action as a result of a customized calling service or 
an enhanced feature. In response to the instructions, the SSP moves through the remaining call 
states, may encounter further triggers, and generates further packets that are used to set up 
and route the call. Similar devices for routing calls among various local exchange carriers are 
provided by regional STP (not illustrated) and by regional SCP (not illustrated) which may be 
connected to STP 20, SCP 22, and/or to the elements described herein through the public 
switched telephone network (PSTN) 26. 

Detailed Description Text (22) : 

When a messaging subscriber (such as the person or entity using telephone 14) subscribes to a 
messaging service, an entry or a record is created in a VMS such as VMS 15. Each VMS 15, 17 
includes subscriber administration, message retrieval, send, reply, forward, and mailbox 
maintenance functions, among others. Each VMS 15, 17 includes or is functionally connected 
respectively to a subscriber profile database 28, 30 ( subscriber data) . Each subscriber profile 
database stores subscriber -specific profile information ( subscriber information) for retrieval 
by VMS functions. The VMSs 15, 17 are elements of the messaging system or service. To the 
protected TCP/IP network (s) 32 described below, each of the messaging platforms 15, 17 look 
like a valid TCP/IP element. In support of this, the VMSs 15, 17 may be assigned a TCP/IP (or 
IP) address and/or a domain name. Generally, the TCP/IP or other address or domain name of the 
VMS 15, 17 may be stored in a region-wide messaging directory (RMD) 25 discussed below, or may 
be stored on some domain name server (not illustrated) either in the protected TCP/IP network 
(s) 32, in some other element, or as a separate element. In further support of this TCP/IP 
capability, the VMSs 15, 17 may also provide operations access to mail administrative 
destinations, in addition to subscriber messaging mailbox destinations. In addition, each VMS 
15 or 17 is an SS7 network element and as such is assigned an identifier such as a directory 
number, a destination point code (DPC) or the like. 

Detailed Description Text (23) : 

The VMSs 15, 17 communicate with the SSP and the SCP 'according to the AIN 0.2 Switch — 
Intelligent Peripheral Interface Generic Requirements — 1129-CORE Specification, AINGR: Switch — 
Intelligent Peripheral Interface (IPI) (A module of AINGR, FR-15) ; Document Number: GR-1129; 
Issue Number: 03; Updates : REV01 — October 1998; Issue Date: September 1997; Product Type: 
Industry Requirements and Standards (RS); Component of FR-15, ("GR-1129") which is incorporated 
herein by reference. This GR-1129 describes the use of a Remote Operations (RO) parameter for 
indicating the invocation of a supplementary service. The RO parameter may be used to allow the 
SCP 22 and the VMSs 15, 17 to share information. If the caller or the communication desires to 
exercise an option of an action other than leaving a message, such as an attempt to contact the 
subscriber at the different directory number, the caller or communication provides the 
indication of the action to be taken with respect to the communication. For example, the caller 
may press "0". In response to receipt of the indication of the action by the VMS 206, a 
transmitter (not illustrated) of the VMS 206 transmits a message indicating the action to be 
taken with respect to the communication and indicating a release of the communication by the 
VMS 206. The message may be an GRU-1129 message including a remote operations (RO) parameter. 
The RO parameter may include information indicating what action is to be taken with respect to 
the communication such as a transfer of the communication (away from the VMS 206) . This 
information may be stored in a field of the RO parameter such as a field denominated as an 
"operation type" field. 

Detailed Description Text (26) : 

Advantageously, a subscribers line number generally may be the subscriber 1 s mailbox number 
associated with a messaging platform rendering service to the subscriber in the RWM system. In 
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other words, a message addressed to the subscriber may include the subscriber 1 s line number, 
which may also be the subscriber 1 s mailbox number. Alternatively, the subscriber 1 s mailbox 
number may relate to some other identifier associated with the subscriber . The subscriber's 
address may be based on the ten digit directory number (DN) using an International 
Telecommunications Union (ITV) Standard E.164 compliant address. 

Detailed Description Text (27) : 

FIG. 1 also illustrates the exemplary use of a region-wide messaging directory 25 (RMD or 
directory) in the messaging system 10. The RMD 25 is functionally connected to the other 
elements of the messaging system 10 through inclusion in or a connection to the TCP/IP network 
32. Although the RMD 25 is illustrated as connected to the system 10 through the TCP/IP network 
32, the RMD 25, or course, may be connected to the system 10 in other ways or even be included 
in an element of the system such as in association with the directories 24 of SCP 22. An RMD 
provides high-speed directory look-up for messaging subscribers . Generally, an RMD stores 
information so as to determine which messaging platform of the RWM system serves which 
subscriber . Additional information on the manner in which the RMDs of the messaging system 10 
store information on messaging platforms and subscribers and how RMDs interact with a network 
element 51 may be obtained from the commonly assigned and owned patent application entitled 
"Methods and System for Determining Message Routing Based on Elements of a Directory Number", 
which was filed with the United States Patent and Trademark Office on Dec. 13, 1999 and 
assigned Ser. No. 09/459,498, and which was filed with the United States Receiving Office 
pursuant to the Patent Cooperation Treaty (PCT) on Dec. 13, 1999 and assigned Application No. 
PCT/US99/29491 and which application is herein by reference. 

Detailed Description Text (28) : 

Of course, an RMD may keep track of other information relating to subscribers of the RWM 
system. In particular, the RMD may act as both a client and a server with respect to the Light- 
weight Directory Access Protocol (LDAP) . The RMD stores subscriber, service, and other 
messaging data. In addition, the RMD supports the LDAP attributes field for LDAP clients to 
choose the fields that they desire to retrieve from the server. Clients may retrieve the 
subscriber profile from the RMD. 

Detailed Description Text (29) : 

Subscriber data may be stored in the RMD in the following exemplary fashion: 
Detailed Description Text (30) : 

Subscriber data is used to look up subscribers in the RMD. The data is also used for the 
purposes of routing and billing a subscriber ' s calls and messages to and from the messaging 
platforms . 

Detailed Description Text (32) : 

The service data contains messaging platform-specific information to perform certain checks 
during directory look-up and call/message routing. The RMD may also store service provider data 
to ensure that a service provider has access to only its authorized subscribers 1 information. 

Detailed Description Text (36) : 

The RWM system 40 of FIG. 2 includes a data network 42, which may be the internet, an intranet, 
or other data network using at least one standard protocol to transmit messages through the 
data network. A standard protocol may be the Transmission Control Protocol/Internet Protocol 
(TCP/IP), the Lightweight Directory Access Protocol (LDAP), which is a TCP/IP-based derivative 
of the X.500 electronic mail (e-mail) delivery service, Profile for Internet Mail (VPIM) 
protocol, or the like. 

Detailed Description Text (37) : 

In the exemplary RWM system 40, the data network 42 is connected to a network A 44 such as a 
segment of the public switched telephone network (PSTN) or similar network. Network A 44 
includes a voice mail server (VMS) A 46, which is operated by a service provider to provide 
messaging services to subscribers such as user A 48. 

Detailed Description Text (38): 

The data network 42 also is connected to a network B 50, which may be a different segment of 
the PSTN or similar network from that segment of the PSTN represented by network A 44. Network 
B 50 includes two voice mail servers (VMSs) 52, 54. In this example, each VMS 52, 54 is 
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operated by a different service provider from the other and from the service provider of VMS 46 
in network A 44. Each VMS 52, 54 is operated by its service provider to provide messaging 
services to a respective group of subscribers . VMS B 52 provides messaging services to user B 
58. Network B 50 also includes a directory 56 such as a Regional Messaging Directory (RMD) 
described above or similar directory. Network B 50 uses directory 56 to determine the address 
of or other routing information for a message received from the data network 42. In this 
example, the directory keeps track of which users ( telephone numbers, directory numbers, 
addresses, or the like identifiers) are served by which of the two VMSs 52, 54. 

Detailed Description Text (44) : 

FIG. 3 shows that SCPs 226, 228 are each coupled to a regional messaging directory ( 11 RMD" ) 240, 
242, respectively. RMDs 240, 242 may also act as an LDAP server responding to LDAP clients 
(like VMSs), able to respond to various LDAP queries by replying with the information indicated 
in the LDAP fields. Generally, RMDs 240, 242 provide a central location for subscriber 
information management. Initially, the RMDs 240, 242 may store only subscribers 1 212 e-mail and 
SMTP server addresses, but they may contain placeholder attributes or pointers for information 
presently stored in VMSs 244, 246 such as a subscriber' s name announcement (a.k.a. Spoken 
Name), extended absence greeting indicator and sub-mailboxes. RMDs 240, 242 may be physically 
deployed on an SCP 226, 228 or, preferably, may reside on a server (computer) and be linked to 
the SCPs 226, 228 via an appropriate network connection. RMDs 240, 242 may be configured as an 
Oracle. TM. database available from the Oracle Corporation deployed on an AIN SCP available from 
Lucent. Other reliable platforms and databases may be used to implement RMDs, 240, 242, 
including UNIX-based or WindowsNT servers. 

Detailed Description Text (45) : 

As noted above, each RMD 240, 242 may store various types of information. For example, each RMD 
240, 242 stores and maintains subscriber profile information that may consist of the types of 
information set forth in the exemplary tables above. SCPs 226, 228 access RMDs 240, 242 in 
order to respond to LDAP messaging queries by providing the information requested by the 
inquiring VMS 244, 246. This information can include: validation of the number provided by the 
subscriber, other subscriber information like spoken name, etc. or the addresses of the network 
element from which such information may be retrieved. Subscriber data is used to look up 
subscribers in the RMD. The data is also used for the purposes of routing and billing 
subscriber calls to and from the messaging platforms. 

Detailed Description Text (46) : 

Service data also may be stored in the RMD as illustrated by the tables above. The service data 
contains messaging platform-specific information to perform certain checks during directory 
look-up and call routing. The RMD may also store service provider data to ensure that a service 
provider has access to only its authorized subscribers 1 information. 

Detailed Description Text (48) : 

A Subscriber Table stores the information concerning the State and LATA (or other appropriate 
political, regulatory or geographical area) in which each VMS resides, as well as the service 
provider operating that VMS. 

Detailed Description Text (52) : 

VMSs 244, 246 may use LDAP for retrieving subscriber profile information. Both RMDs 240, 242 
and VMSs 244, 246 may interchangeably act as a LDAP client as well as a directory server. RMDs 
will support primary and secondary LDAP queries so that initially destination information can 
come from RMDs 240, 242 (via a primary query) and spoken name and other subscriber information 
can come from other VMSs (via secondary queries) within the system 200. VMSs 244, 246 may query 
RMDs 240, 242 for subscriber profile information, essentially acting as a LDAP client. VMSs 
244, 246 will request all subscriber attributes, but RMDs 240, 242 will return only usable 
values for email and SMTP addresses. When VMSs 244, 246 receive the attributes that are 
unusable values but represent placeholders for such profile information as the spoken name, 
sub-mailboxes etc., an originating VMS 244, 246 will act as a server, initiating a secondary 
query to a particular, client VMS for that information. For instance, VMS 244 may act as a LDAP 
client, retrieving subscriber information like the subscriber 1 s spoken name announcement by 
querying RMD 240, which either returns the spoken name or returns information indicating VMS 
246 retains the subscriber 1 s spoken name. VMS 244 thereafter sends a secondary query via VMS 
network 252 to VMS 246 to retrieve the stored spoken name. 
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Detailed Description Text (53) : 

FIG. 4 shows the general network topology and interrelation between a VMS 246 acting as an LDAP 
client seeking subscriber information from RMD 240, which in turn queries a VMS 244 acting as 
an LDAP server to retrieve a spoken name. Alternatively, all subscriber information may be 
stored in and retrieved from RMDs 240, 242, which may also retrieve subscribers ' spoken names 
directly from VMSs. VMS 244, 246 queries to RMDs 240, 242, may use the domain name scheme 
described in the AIM2000 Service Deployment Architecture, attached and previously incorporated 
by reference. Additionally, detailed call flows showing the various LDAP queries and responses 
among the network elements shown in FIGS. 3 and 4 are described in further detail in the 
"AIM2000 Service Deployment Architecture (Issue 1.0)" document, attached to the referenced 
provisional application and previously incorporated by reference. 

Detailed Description Text (54) : 

Using the LDAP query scheme described above, the present invention facilitates VMSs 244, 246 
access to subscriber profile information stored in RMDs 240, 242. For instance, when a message 
is to be delivered among subscribers to system 200, one VMS 244 will query the appropriate RMD, 
providing the destination and origination addresses (e.g., telephone numbers). The RMD 240 will 
associate those addresses with the applicable VMS serving those subscribers, which will also 
provide information concerning the geographic location of the VMS and the service provider 
operating the VMS. Then, using rules provided within its database, RMD 240 will determine 
whether regulatory, business or other constraints prohibit a messaging transaction between the 
identified VMSs of the message sender and recipient. 

Detailed Description Text (56) : 

Certain subscribers may elect to use a message delivery service that allows subscribers 200 to 
create a multiple distribution list by which messages can be broadcast to multiple recipients. 
The distribution list can include other subscribers to regional messaging system 2 00 and non- 
subscribers (although the non - subscribers must have at least the traditional voice mail 
services ) . 

Detailed Description Text (57) : 

As the subscriber 212 creates the distribution list by inputting various telephone numbers, 
validation of the proposed messaging transaction to each destination number may be performed. 
Validation proceeds as follows. . Subscriber 212 seeks to send a message to caller 210. 
Subscriber 212 enters caller 210's telephone number into a message delivery list ( "MDL" ) . VMS 
246 receives subscriber 212 ! s entered list, including caller 210's telephone number. VMS 246 
queries RMD 242, providing the caller 210's telephone number, as well as information 
identifying the subscriber 212. The RMD 242 uses the Tables I and II described above to 
determine the identity of the service provider serving caller 210 and the geographic location 
of both caller and subscriber . 

Detailed Description Text (58) : 

With the above-described information concerning caller 210 and subscriber 212, RMD 242 is able 
to apply the rules set forth in the tables within RMD 242 to determine whether a message from 
subscriber 212 would be allowed. For instance, suppose subscriber 212 were located in Georgia 
and caller 210 located in Louisiana. Table II informs RMD 242 that an interstate message 
transfer between VMSs located in Georgia and Louisiana is allowed. The next step is to 
determine whether the VMSs involved different service providers. Table II informs RMD 242 that 
subscriber 212' s VMS 2 is operated by BellSouth and that caller 210 , s VMS1 by Evelyn's Voice 
Mail. With that information, RMD 242 examines Table III to determine whether Evelyn's Voice 
Mail accepts message traffic from BellSouth. It does, so the transaction is validated. 

Detailed Description Text (59) : 

Each number of a regional messaging service subscriber that is entered into the MDL is verified 
through a similar process. If RMDs 240, 242 determine that state regulations do not allow 
interstate message traffic (e.g., if a participant in the proposed messaging transaction is in 
Alabama), the telephone number will not be validated. Or, in another example, if the message 
transaction is only inter-LATA, it would be allowed in North Carolina, but not Alabama. In yet 
another example, if the message transaction involves exchange of messages within North 
Carolina's "424" LATA, the method of the present invention determines such an exchange is 
allowed by regulation. But if the same transaction involves a recipient whose service providers 
were, for instance, Harry's VoiceMail, RMD 240, 242 determines from Table III that message 
exchange with Harry's VoiceMail is not allowed. 
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Detailed Description Text (60) : 

Once validation is complete, the subscriber 212 is alerted to the validation by the spoken name 
confirmation process described below. If a recipient is a non - subscriber 42, an announcement 
will so indicate, including the non -subscriber 1 s 42 phone number. Thereafter the subscriber 
212 f s VMS may simply store that number for later outdialing and playing of the message, as 
described below. Typically, a confirmation spoken name may be given for subscriber 1 s 212 and a 
confirmation telephone number for non -subscribers 3. 

Detailed Description Text (61) : 

When a distribution list is completed and the subscriber 212 orders the message circulated, 
messages to subscribers 212 are formulated into the VPIM format and sent via the TCP/IP network 
252 described above. Messages to non -subscribers 3 will be "outdialed. " In other words, 
messages will be forwarded to the subscriber 1 s 212 local switch-or SSP, such as SSP 222. There, 
the message encounters a trigger (e.g., a TAT or Terminating Attempt Trigger) that makes the 
SSP 222 query the SCP 228 for the destination of non -subscriber 42 indicated in the list. This 
is a billing mechanism that is also used for flexible call forwarding features that is 
described in U.S. Pat. No. 5,991,377 that is owned by the assignee of the present invention and 
which is hereby incorporated in its entirety by this reference. SSP 222 thereafter dials an 
actual call, connecting the subscriber's VMS to the non -subscriber 1 s voice mailbox so that the 
recorded message may be played and recorded in the non -subscriber 1 s voice mail. In order to be 
compatible with caller ID services, the calling number field will display an appropriate name, 
like "[Name of the Messaging Service Provider] Messaging." Alternatively, the messaging service 
provider may itself route the call, selecting the route and carrier. Note that because non- 
subscriber messages are outdialed via a normal telecommunications call, they are not subject to 
the regulatory and business constraints for messaging traffic and will not need to be validated 
against those conditions. 

Detailed Description Text (63) : 

In FIG. 3, a caller 210 sends a message to a subscriber 212. Caller 210 either calls subscriber 
212 's voice mailbox to leave a message or caller 210 originates a message in VMS 244 that 
ultimately is intended for subscriber 212' s voice mailbox on VMS 246. Subscriber 212 receives 
the message and desires to formulate a reply to the caller 210. 

Detailed Description Text (64) : 
Replies to Other Subscribers : 

Detailed Description Text (65) : 

While the subscriber 212 listens to caller 210 ! s message, VMS 244 queries SCP 226 to determine 
whether the caller 210 receives voice mail services from a service provider participating in 
regional messaging system 200. The VMS 244 query sends to the SCP 226 the caller 210* s 
telephone number and the subscriber 212 ! s telephone number. VMS 244, of course, stores 
subscriber 212's telephone number. 

Detailed Description Text (66): 

The present invention, using the process and system described above, will discern the service 
provider, LATA, and State of each party to the proposed transaction. Thus, the subscriber 212's 
VMS 246 queries the RMD 242 using LDAP queries forwarded over the VMS network 252 to ascertain 
the location of the VMS operating the recipient's voice mail service and the service provider 
operating that VMS. RMD 240, 242 will then apply the applicable regulatory constraints or 
business constraints stored in various tables, such as tables I through III above, to determine 
the validity of going forward with the proposed reply transaction. 

Detailed Description Text (68) : 
Replies to Non -Subscribers : 

Detailed Description Text (69): 

Replies to non -subscribers need not be validated on regulatory and business 
although there will have been an earlier validation query that confirms the 
to a subscriber . In that case, RMDs 240, 242 need not be further queried to 
destination of the reply. 

Detailed Description Text (70) : 
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Instead, the subscriber 212 f s VMS 246 simply stores calling line identification ("CLID" ) 
information available when the non - subscriber calls to leave a message in subscriber 212 's 
voice mailbox. If the CLID information is not designated as private, VMS 246 will play the 
telephone number as confirmation of the non - subscriber recipient. In any event, either after or 
during composition of the message, VMS 246 causes an actual call to be outdialed to the non- 
subscriber, as described above, through the subscriber 212 's serving SSP 222 directly to the 
designated number so the message may be left. 

Detailed Description Text (72) : 

Accurate delivery of messages is important to voice mail subscribers 200, who do not wish 
possibly confidential messages to be misrouted. To decrease subscriber 212 error in identifying 
message recipients, when a subscriber 212 chooses the reply option, the subscriber 1 s VMS 246 
plays a confirmation of the reply destination, called the confirmation name announcement. 

Detailed Description Text (73) : 

If subscriber 212 chooses to reply to a message from caller 210 by entering the appropriate 
code or otherwise indicating that choice, VMS 246 queries the SCP 228 to retrieve the original 
caller 210 ! s spoken name. Assuming caller 210 subscribers to system 200, SCP 228, in turn, 
accesses the RMD 242 to retrieve either the caller 210 f s spoken name or a pointer that 
identifies to VMS 246 the appropriate VMS messaging platform (e.g., VMS 244) to query for that 
spoken name. If the spoken name resides on a different VMS, VMS 246 is so informed by a reply 
LDAP message from SCP 226. Thereafter, VMS 244 launches another query to VMS 246 to retrieve 
the caller 210 's spoken name. The spoken name is played to the subscriber 212 as confirmation 
that the reply will be forwarded to the intended recipient. Upon hearing the name, the 
subscriber 212 records the reply message. When the reply message is complete, the subscriber 
212 so signals VMS 246 via entry of the appropriate codes . VMS 246 packages the reply and 
routes it back to the caller 210 ! s VMS 244 using the information retrieved via SCP 226 from RMD 
228. 

Detailed Description Text (74) : 

If the calling name is unavailable, the messaging system 200 should play- the calling number, if 
available, or other appropriate announcement to confirm the subscriber 212's choice. For 
instance, a text-to-speech rendering may be made of the caller 210' s text-stored name or the 
originating number of the caller 210 may be provided to the subscriber 212 in order to inform 
the subscriber 212 of the identity of the message's recipient, caller 210. 

Detailed Description Text (76) : 

The preferred embodiment of the regional messaging system 200 described above for use with the 
present invention supports the use of messaging to "sub-mailboxes." Sub-mailboxes are multiple 
mailboxes that can be accessed by dialing a single telephone number and then selecting a code 
that identifies a particular mailbox. For instance, a sub-mailbox may be identified by an 
additional number (00, 01, 02, etc.) associated with the main telephone number. Users control 
uses of submailboxes . and may change which boxes are used for which users. If a subscriber 
attempts to send a message to a submailbox (either through the reply or message distribution 
options), the LDAP query process described above will be used to determine whether the 
submailbox exists. Subscribers will be informed if that mailbox is invalid. 

Detailed Description Text (77) : 

The preferred regional messaging system 200 in which the present invention may be deployed 
accepts facsimile messages and stores them in a particular subscriber's VMS 244, 246. Facsimile 
data in certain protocols (like Group 3 fax messages) can be stored, forwarded to an 
appropriate printer or computer for written display or annotated. Facsimile messages may be 
forwarded like other messages using the same general process described above. When the 
subscriber 212 chooses a forwarding address involving a toll payment, the procedure described 
above may first be used to determine the location of the VMS serving that number. Other 
databases deployed at the RMD 240, 242 or the subscriber's VMS 244, 246 may determine whether 
that location will incur toll charges and an appropriate announcement may be played so 
notifying the subscriber 212. 

Detailed Description Text (78) : 

Subscribers, in setting up their accounts, may be offered the option of associating a facsimile 
number with the subscriber ' s mailbox number. This allows such subscribers to receive voice 
replies to facsimile messages. Those replies may be made by generally following the same 
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process used to determine if a reply to a voice message may be made. Thus, the VMS 244, 246 
determines whether the RMD 240, 242 lists the calling number associated with the facsimile 
number that was appended to the facsimile message left in the subscriber 1 s voice mail. If there 
is an associated calling number, the subscriber retrieving or re-directing a facsimile message 
is offered the option of voice replying to the originator's mailbox. 

Detailed Description Text (79) : 

RMDs 240, 242 may be implemented so that, as part of the profile information, it stores the 
spoken name of each subscriber to affiliated providers 1 services. In that case, the third party 
service providers may accept messages from the regional messaging system 200 by simply 
configuring their VMS to process messages that are in the appropriate format, such as the VPIM 
format described above. In other words, storing the spoken name at RMDs 240, 242 allows 
providers to more easily configure their voice mail systems to accept messages generated by 
system 200. 

Detailed Description Text (81) : 

The present invention can also be deployed over other existing network, including a TCP/IP 
network. For instance, the present invention can be deployed over the internet. That can be 
accomplished by having users associate with their phone numbers their e-mail addresses. When a 
particular user desires to forward a message to another user part of the regional messaging 
system, the user's messaging server can utilize the process of the present invention to launch 
queries to the directory to determine whether or not the recipient is also participating in the 
region-wide messaging system. By retrieving the recipient's IP address (e.g., e-mail address), 
the present invention can thereafter formulate the originating subscriber ' s message and send it 
as a file attachment via e-mail to the message recipient. The e-mail attachment can be either 
an audio link or a transcript of the originating party's voice message. Such a transcript can 
be prepared using commercially available voice-to-text conversion software, which can be 
deployed on the same platform that holds the directory information. 

Detailed Description Paragraph Table (1) : 

Description/Directory Field LDAP DN Attribute Subscriber ' s Mailbox Number CN (Common Name) Name 
Announcement Spoken Name MDSBlocking N/A 

Detailed Description Paragraph Table (3) : 

Subscriber Table I Subscriber Identifier VMS Identifier Block Flags 770-555-1212 
6110.atlngamm62 Subscriber in default; [e.g., VMS1 run by subscriber language BellSouth] 
features. 404-555-1212-02 2113 . atlngaev63 [e.g., VMS 2 Subscriber authorized run by Evelyn's 
Voice Mail] for messaging 336-555-1212 4331 . atlngahh69 [e.g., VMS 3 Subscriber paid up run by 
Harry's VoiceMail] and authorized 

Other Reference Publication (5) : 

"General Recommendations on Telephone Switching and Signalling — Introduction to Intelligent 
Network Capability Set 1", International Telecommunication Union, XP-002141945, Mar. 1993. 

CLAIMS : 

3. A method according to claim 2 wherein the querying is performed by providing the messaging 
directory with at least the message recipient 1 s telephone number correlated to at least the 
identities of one of the first or second voice mail servers. 

14. A method according to claim 8 further comprising out-dialing a telephone call to a person 
not subscribing to regional messaging services in order to deliver a message. 
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DOCUMENT-IDENTIFIER: US 6498791 B2 

TITLE: Systems and methods for multiple mode voice and data communications using intelligently 
bridged TDM and packet buses and methods for performing telephony and data functions using the 
same 

Abstract Text (1) : 

Systems and methods by which voice/data communications may occur in multiple modes/protocols 
are disclosed. In particular, systems and methods are provided for multiple native 
mode/protocol voice and data transmissions and receptions with a computing system having a 
multi-bus structure, including, for example, a TDM bus and a packet bus, and multi-protocol 
framing engines. Such systems preferably include subsystem functions such as PBX, voice mail 
and other telephony functions, LAN hub and data router. In preferred embodiments, a TDM bus and 
a packet bus are intelligently bridged and managed, thereby enabling such multiple 
mode/protocol voice and data transmissions to be intelligently managed and controlled with a 
single, integrated system. A computer or other processor includes a local area network 
controller, which provides routing and hub(s) for one or more packet networks. The computer 
also is coupled to a buf fer/f ramer, which serves to f rame/def rame data to/ from the computer 
from TDM bus. The buf f er/ f ramer includes a plurality of f ramer/def ramer engines, supporting, 
for example, ATM and HDLC f raming/def raming . The buf fer/ f ramer is coupled to the TDM bus by way 
of a switch/multiplexer, which includes the capability to intelligently map data traffic 
between the buf fer/f ramer and the TDM bus to various slots of the TDM frames. Preferably, a DSP 
pool is coupled to buf fer/f ramer in a manner to provide various signal processing and 
telecommunications support, such as dial tone generation, DTMF detection and the like. The TDM 
bus is coupled to a various line/station cards, serving to interface the TDM bus with 
telephone, facsimiles and other telecommunication devices, and also with a various digital 
and/or analog WAN network services. 

Brief Summary Text (4) : 

Businesses, particularly small to medium size offices, typically have a need for a variety of 
voice and data communications. For example, a typical office might have a dedicated fax 
machine, using a dedicated or shared telephone line, one or more telephone lines for voice 
communications, perhaps coupled to a central or distributed voice mail system(s) , and one or 
more computers or computer networks, often coupled to telephone lines via one or more modems. 
Many offices now use the Internet in some form for business communications or research or the- 
like, often by way of a modem or modem pool coupled to individual computers. 

Brief Summary Text (6) : 

FIG. 1 illustrates a conventional small office communication configuration. Voice communication 
system 1 typically is implemented by way of multiple analog trunks 16 from wide area network 
("WAN") 18. WAN 18 often consists of a telecommunication network by way of a local telephone 
company or other telecommunications service provider. Analog trunks 16 may be directed through 
switching system 10, which may be a conventional PBX or similar telephone switch. Telephones 12 
and voice mail system 14 are coupled to switching system 10. Often, dedicated analog line 16A 
is coupled to facsimile 44 for facsimile communications. 

Brief Summary Text (8) : 

Such a conventional system often is characterized by piecemeal equipment and network solutions, 
limited or non-existent coordination and management between voice system 1 and data system 2, 
non-optimized or non-integrated equipment, and inefficient use of costly network services 
(telephone lines, data lines, etc.), such as duplicate and often idle phone and data network 
lines, often provided from multiple equipment/service providers. In general, such conventional 
systems are neither constructed nor operated in a manner to provide efficient and integrated 
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Brief Summary Text (10) : 

The present invention is intended to address various disadvantages of such conventional 
communication systems. The present invention provides various systems and methods, perhaps more 
succinctly a platform, by which voice and data communications may occur in multiple modes and 
various protocols, and more particularly systems and methods for multiple native mode voice and 
data transmissions and receptions with a communications/computing system having a multi-bus 
structure, including, for example, a TDM bus, a packet bus and a control bus, and multi- 
protocol framing engines, preferably including subsystem functions such as PBX, voice mail and 
other telephony functions, email and/or file server, Internet server, LAN hub and data router. 
With the present invention, a platform and various processes are provided in which a TDM bus 
and a packet bus are intelligently bridged and managed, thereby enabling such multiple 
mode/protocol voice and data transmissions to be intelligently managed and controlled with a 
single, integrated system. 

Brief Summary Text (11) : 

In preferred embodiments, a computer or other processor includes a local area network 
controller, which provides routing and hubs and/or switches for one or more packet networks. 
The computer also is coupled to a multiple buf f er/f ramer, which serves to f rame/def rame data 
to/from the computer from TDM bus. The buf f er/f ramer includes a plurality of f ramer/ def ramer 
engines, supporting, for example, ATM and HDLC f raming/def raming, and raw buffering of voice 
data or the like. The buf fer/ f ramer is coupled to the TDM bus by way of a multiple port or 
multiport switch/multiplexer, which includes the capability to intelligently map data traffic 
between the buf f er/f ramer and the TDM bus to various slots of the TDM frames. Preferably, a DSP 
pool is coupled to one or more switch/multiplexer ports and/or the buf f er/f ramer in a manner to 
provide various signal processing and telecommunications support, such as dial tone generation, 
DTMF detection and the like. The TDM bus is coupled to a various line/station cards, serving to 
interface the TDM bus with telephone, facsimiles and other telecommunication devices, and also 
with a various digital and/or analog WAN network services. The present invention provides a 
platform by which' processing functions may be switched to provide support for a wide range of 
network, vendor and application services. 

Detailed Description Text (5) : 

It will be appreciated that communications system 50 also may implement hardware and software 
for additional network functions, which are included in alternative embodiments. Such network 
functions include, but are not limited to: name server, such as DNS (Domain Naming System, 
which is used in the Internet for translating names of host computers into addresses ) or WINS 
(Windows Internet Name Service, which is a name resolution service that maps or resolves 
Windows networking computer names to IP addresses particularly in a routed environment) ; 
firewall (as is known in the art, a firewall is a hardware/software implement that limits the 
exposure of a computing system such as communications system 50 or computers coupled thereto to 
access from a computer external to the system, which may include a network level firewall or 
packet filter that examines data traffic at the network protocol packet level, or an 
application-level firewall that examines data traffic at the application level, such as FTP or 
file transfer protocol, email, etc.); proxy server (as is known in the art, a proxy server is a 
type of firewall that uses a process known as address translation to map internal user IP 1 
addresses to the IP address associated with the proxy server firewall in order to provide extra 
security, etc.); DHCP (Dynamic Host Configuration Protocol, which is a protocol which allows a 
server to assign dynamically IP addresses to particular computers in real time, etc., which may 
support manual, automatic and/or dynamic address assignment, which may be used to verify a 
particular computer's identify, temporarily assign it an IP address for a particular period of 
time, and reclaim the IP address later for reassignment at the expiration of the particular 
period of time, etc.); and/or email server or gateway (which, as is known in the art, may be 
used to send and receive emails and/or send and receive faxes for the computers connected to 
the LAN or LANs, etc.). 

Detailed Description Text (6) : 

Communications system 50 includes the functionality of what is known as a. PBX (as will be 
described further) . In preferred embodiments, communications system 50 is connected to a 
plurality of telecommunication devices, such as telephones 12, facsimile 44 and other suitable 
telecommunications devices and access and server functions (such as private voice mail, 
recording devices, WAN service interface cards, etc.). What is important is that communications 
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system 50 include interfaces for a plurality of telecommunications devices for the particular 
and complete office/work environment and infrastructure. 

Detailed Description Text (7) : 

Communications system 50 is coupled to WAN voice/data services network (s) 58 through trunks 54. 
Voice/data services network (s) may include private line, local or long distance carrier 
networks, Internet, intranet and/or any other current or future WAN-type network services. 
Trunks 54 may consist of high, medium or low speed digital and/or analog lines, either public 
or private, and in certain preferred embodiments consist of high speed dedicated resources such 
as what are known as T-l, PRI (Primary Rate ISDN), ATM, VDSL, HDSL, ADSL, DDS (Dataphone 
Digital Service, also called Digital Data System) , wireless, cascade, proprietary and/or 
twisted pair analog lines from a local telephone company. What is important is the 
communications system 50 is coupled to WAN services, trunks and the like in a manner that the 
user, service provider, administrator and/or algorithm has determined will provide adequate or 
required resources, on a cost-effective basis, for the particular office/work environment and 
operating conditions. 

Detailed Description Text (10) : 

Communications system 50 is controlled by host processor/system resources 70, which in 
preferred embodiments include a computer powered, for example, by a commercially available or 
other microprocessor and an embedded and/or commercially available operating system. What is 
important is that processor/system resources 70 provide sufficient processing power, memory and 
storage resources (RAM, ROM, hard disk, magnetic or other storage, etc.), bus and other 
resources in order to control the various subsystems and components as will be described. In 
particular, computer/system resources 70 enables automatic internal negotiation, control and 
enabling of services and applications. Although not expressly shown, processor/system resources 
70 also may include other components of a relatively high-end personal computer, workstation or 
server, such as a display device, keyboard, serial ports, parallel ports, power supply and the 
like. The various subsystems and components of communications system 50 are intelligently 
controlled, managed and monitored by processor/system resources 70. Processor/system resources 
70 provides system and server management software and the like, and a platform for various 
server applications as described herein. 

Detailed Description Text {12) : 

Processor/resources 70 also may be connected to DSP 76. DSP 76 preferably consists of a single 
digital signal processor or multi-digital signal processor resource pool, which serves to 
provide a variety of functions within communications system 50. In preferred embodiments, DSP 
76 generates dial tones (such as for telephones 12), DTMF digit detection and decoding, echo 
cancellation, coding/decoding functions, voice conferencing, voice compression, voice 
recognition and the like. In other embodiments, DSP 76 performs data compression, transcoding, 
processing for voice communications using an Internet protocol ("IP") or other voice over other 
network protocol or the like. In general, DSP 76 provides a set of processing and memory 
resources to support the various voice/data services controlled and managed by 
processor/resources 70. As illustrated by bus connection 84A, DSP 76 alternatively may be 
coupled directly to TDM bus 78. 

Detailed Description Text (14) : 

Coupled to TDM bus 78 are line, station, trunk, or other interface cards 82. Cards 82 provide 
CODEC, line interface, off-hook detect and other functions as are known in the art to support 
various telecommunication devices (such as telephones 12 and facsimile 44) and WAN-type network 
services (such as voice/data services 58) that are communicating with communications system 50 
via TDM bus 78. In preferred embodiments cards 82 provide points of termination for a plurality 
of telephones 12, one or more facsimiles 44, and various T-l, PRI, ATM, analog and/or other 
WAN- type network services as determined by the particular office/work environment. Cards 92, 
under control of processor/system resources 70, may include points of termination for emergency 
or backup telephone services and the like, such as in the event of a power failure or to 
provide analog services in the event a dedicated resource such as a T-l is unavailable for some 
reason. 

Detailed Description Text (30) : 

Server encryption applications 23 may be provided in order to provide encryption or similar 
coding or processing of voice/data communications processed by communications system 50. VoIP 
gatekeeper 25 may be provided to service and control voice over Internet protocol ("VoIP") 
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communications. As more specifically described below, various types of VoIP communications may 
be' effectively managed and controlled in accordance with preferred embodiments of the present 
invention, such as, for example, a determination that acceptable conditions exist on the 
Internet for such communications. Directory 27 may be provided in order to make various types 
of directory information available, to users of communications system 50. Directory information 
provided by directory 27 may include names, telephone extensions, address or other personal or 
work information regarding persons or departments, etc., serviced by communications system 50. 
Directory 27 also may include similar directory type information for persons or departments, 
etc. in a remote or other locations, such as may be accessed through voice/data services 58. 

Detailed Description Text (36) : 

For example, data switching services may be provided such as by LAN/NDIS/DDI drivers 39 (LAN, 
NDIS and DDI being exemplary) through hardware modules such as switched Ethernet 45 and hub 47. 
Routing services may be provided such as through WAN drivers (specific network services such as 
PRI and T-l being exemplary) through hardware modules such as T-l module (s) 49, ISDN module (s) 
51, central office-plain old telephone service (CO-POTS) module (s) 53, V.35 module (s) (it 
should be understood that various hardware modules may be utilized in accordance with preferred 
embodiments of the present invention, as desired to implement the various data switching, 
routing and other communications connections as may be determined by the needs of the 
particular office/work environment. PBX station services, such as automated attendant, 
reception, voice mail and the like, may be provided through station manager 43. Station manager 
43 provides hardware for connection to various telecommunications devices, such as phones 12, 
facsimile 44, etc. In general, station manager 43 provides sufficient interface hardware in 
order to connect to the various devices that may be determined by the needs of the particular 
office/work environment) . 

Detailed Description Text (37) : 

Additional features particularly of hardware components of such embodiments involving detection 
operations incorporating or utilizing DSP resources such as are included in preferred 
embodiments will now be described (DSP resources included in such embodiments are described, 
for example, in connection with FIG. 3. A technique for determining characteristics of an 
analog line is to send a known signal (preferably a known tone or combination of tones or 
frequencies of known energy, etc.) down a line, and convert a predetermined frequency (or 
frequencies) of a returned signal from the analog line to a voltage or to otherwise process the 
returned signal; characteristics of the analog are determined based on the voltage or otherwise 
from information extracted from the returned signal. In preferred embodiments the returned 
signal is processed by DSP resources (see DSP 76 of FIG. 3) in order, for example, to perform a 
Fast Fourier Transform ("FFT" ) or other signal processed on the returned signal. As example, 
particular frequency bands in the returned signal could be evaluated to determine whether a 
phone is physically connected to the line (e.g., an analog phone typically presents a 10K ohm 
impedance to the line in an on-hook condition, the presence of which could be determined by 
evaluation of the returned signal. In preferred embodiments, DSP resources could evaluate the 
returned signal energy, again preferably with an FFT, and the presence and/or type of telephone 
device physically attached to the line could be assessed/determined, and still preferably an 
assessment of the quality of the particular line could be made based on such an analysis of the 
returned signal. 

Detailed Description Text (38): 

Such signal processing could be done periodically or upon detection of errors, start-up or 
reboot, or upon initiation of a diagnostic or maintenance routine. With remote administration 
and configuration capabilities as described elsewhere herein, such phone presence detection, 
line quality assessment, etc., could be conducted from a remote location (such as enabling a 
central system administration to "map" the presence of phones to particular lines in a remotely 
located system. In accordance with such embodiments, such capability enables a similar 
functionality to the link status indicators that may be available on network ports. Such link 
status information for analog telephones can be incorporated into a visual representation of 
the system, easily viewable remotely via an HTTP link over the Internet, for example (such 
remote viewing of the physical status of a system, i.e., "chassis view," is described elsewhere 
herein) . It should be understood that this approach to obtaining line status and information 
can easily be applied to other aspects of telephone lines. For example, the line condition, or 
suitability for high speed data transfer, or perhaps the highest speed available on a 
particular line (e.g., "speed grading" or "speed characterization" of individual lines) can be 
measured. 
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Detailed Description Text (43) : 

In the event a user picks up one of telephones 12, an off-hook condition is detected by the 
appropriate card 82, which signals processor/system resources 70 of the off-condition. 
Processor/system resources 70 controls switch/multiplexer 74 to couple the appropriate card 82 
to DSP 7 6, which generates a dial tone that is coupled to the appropriate telephone 12. The 
user hears the dial tone and may then proceed to place the desired call. DSP 76 detects the 
digits of the telephone number of the desired call and provides the detected digits to 
processor/system resources 70. For an internal call, processor/system resources 70 directs that 
the called internal telephone receive a ring signal from the appropriate card 82. Upon pick-up 
of the called internal telephone, the telephone connection between the internal phones is 
established by way of TDM bus 78 and the appropriate cards 82. 

Detailed Description Text (45) : 

Incoming calls are detected by the appropriate cards 82 and signaled to processor/system 
resources 70. Connections of voice incoming calls to telephones 12 are established under 
control of processor/system resources 70 over TDM bus 78. 

Detailed Description Text (49) : 

In accordance with preferred embodiments of the present invention, one or more of computers 24 
may execute a PBX/telephony control application software program. In accordance with the 
PBX/telephony control application, hereinafter referred to as the "office attendant type" 
program, control of the telephony and related functions of communications system 50 may be 
intelligently managed and controlled. With such an arrangement, one or more computers on the 
LAN may be used to control incoming and outgoing calls of the office using the computer in a 
natural and intuitive manner. A telephony headset or telephone preferably is associated with 
the particular computer that will be running the office attendant type program to enable 
traditional voice communications with incoming callers, etc. 

Detailed Description Text (50) : 

As illustrated in FIG. 6, a party desiring to control the incoming and outgoing calls and/or 
station to station calls of the office ("attendant 1") may log-on and run the office attendant 
type program from one of the computers connected to the LAN connected to communications system 
50. At step 100, attendant 1 may be required to enter an appropriate user name/ID and password 
in order to recognize attendant 1 as an appropriate user to assume control of the telephony 
functions of the office. A network or systems administrator may set up password control for 
parties authorized to run the office attendant type program. At step 102, in preferred 
embodiments the computer running office attendant type program has downloaded to it the current 
telephone subscriber directory such as over packet bus 80A or 80B of FIG. 3 (e.g.: a complete 
listing of the telephone subscribers; extensions; status information such as do not disturb, 
forward and forwarding information, forward to voice mail, hunt group information, etc.) from 
communications system 50. In this manner, the computer or computers running the office 
attendant type program may locally contain current subscriber information for controlling the 
incoming and outgoing calls of the office. In preferred embodiments, communications system 50 
automat ix^J^y -o^^ e.g., a s ubscriber Jias been add ed ^ 

to_ox-del. ef . ed fx r in t^he ^eJ^ph-o^^ an extension has change^T^I or a suSscriber 's — 

status information has changed, or any state a,s^c^Fa%ed==»w4^h-- eommun i cat ions system 50 , etc77~ln 
order th at updates may_b e timel y^ madgiza^a£i.ab-le . In such embodiments, computers runnin^pthi"^ 

"office attendaiTt^tTy pe^ program may be updated promptly and_ , au£pjnaticallY^ bv--com^ ' 

system 50 so as to contain current subscribe r inf ormation^ou.^i^QngpjLng basis to more 
e^l~c^gn^Ty~ ^ntrol tele phony, operation^ qf^Tn^'of f ice .__It also should be noted that in 
preferred embodiments the subscriber information also mayHLmrllodF^fn^ 

the email address and extended dire ctory inform ation including personal information manager 
("PIM") information of the particular subscriber an d netwo r k_ldenfI! £Tca ti5 jT~f c7r^"a^cl5mputer~' 
as socia ted with the parti cular subscriber^ With such i nfo rma t i on .^n e-t— me s s a,g e s or otfrer--^^ 
c ommu n ica"if i o n s with particular subscribers may be facilitated as more fully de^crTBed^he-rein . 



D e t a rTe^~De^irrxpt-ron~"T ex t — (~51T: — — " " ' 

It also should be noted that this subscriber download concept is applicable in various forms to 
all computers coupled to communications system 50. For example, communications system 50 
includes information regarding all users registered in the PBX (i.e., all users having a 
telephone extension and/or computer coupled to communications system 50 such as over the LAN or 
WAN) . Thus, in the event of a subscriber directory change, communications system 50 may 
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"broadcast" updated subscriber directory information to all computers coupled to communications 
system 50, or, in alternate embodiments, communications system 50 sends a net message, email or/ 
other message to such computers coupled to communications system 50 that prompts the users of 

such computers to the a vailability of the subsc riber directory updat ,R f (p v . g, , the remo te^ . 

computers recelv^ d ' a 1 iff essage indicting the availaHiTTty of the subscriber directory update, 
which preferably includes an "accept" icon and a "reject" icon, thereby enabling the user to 
receive or not receive the update as he/she may desire) . 



Detailed Description Text (58) : 
Referring to FIG. 22, the Main Window preferably includes a small appearance GUI footprint 
including three low profile line status indicators. Office communicator-type programs 
preferably do not include a 'Calls in Queue' or a 'Calls on Hold' indicator. Alternative views 
of this window can be sized and displayed to take up less physical space on the screen for the 
end user. Such feature buttons allow additional functionality to be added into the program, for 
example, multiple call parking features can be added. In this example, there are two types of 
park: Self-Park and System Park. Self-park preferably parks the call at the extension of the 
person parking the call. Hence, if an outside caller calls extension xl25 and the user at xl25 
answers and self parks the call, then the user at xl25 can page and announce "Pick up xl25". 
System park returns a parking address, or slot number of a predetermined number of parking 
spaces that the system allocates for such call parking. Hence, if an outside caller calls 
extension 125 and the user at xl25 system parks the call, then the display on ext 125 f s office 
communicator-type program will read: "Call Parked on <slot number>", e.g. "Call Parked on 2". 
Then the user at xl25 can page, and announce "Pick up 2". 

Detailed Description Text (59) : 

Referring now to FIG. 23, such an office communicator type program that is optimized for 
general telephone and computer use, can include a screen pop window as illustrated. The main 
user interface illustrated in part in FIG. 22 preferably consists of a three-line display. 
However, this main user interface is not intended to be maximized at all times. When an 
incoming call arrives, the screen pop illustrated in part in FIG. 23 will slide out and occupy 
a small portion of the screen to let the user know that there is an incoming call, and provide 
caller information to the user. In addition, such a screen pop may incorporate a visual signal, 
e.g., a rotating telephone icon, to help indicate that a call is trying to get through. When 
there are new messages at the extension, the screen pop will also appear to indicate (via an 
appropriate icon or other indicia, preferably rotating or otherwise moving in order to attract 
visual attention,, etc.) that there is a message waiting. For making outbound call and other 
simple/more frequent call control operation, a toolbar with basic call control functions 
preferably is provided to the user. Other visual and operational variations suitable for other 
working environments will be apparent from the above discussion. 

Detailed Description Text (64) : 

The user preferably may also initiate a call from the phone. The user would pick up the phone 
and hear dial tone. He or she can then dial the number from the phone set. When the user is 
already on another call and he wants to make another call by the application, he can choose to 
put the current caller on hold and dial the number, or the application would automatically put 
the current caller on hold when he dials the number. When the user is already on another call 
and he wants to make another call by the phone, he can put the current caller on hold by 
hitting 'FLASH' on the phone and dial the number. 

Detailed Description Text (65) : 

The user can put a current call on hold using the mouse, by using the keyboard or by using the 
phone. By making an outbound call, or answering another call from the application, the current 
call can automatically be put on hold by the application. The user can put the current call on 
hold from the phone, for example, by hitting 'FLASH' on the phone set. 

Detailed Description Text (74) : 

During the transfer of a call, if the destination extension is on the phone or on DND (Do Not 
Disturb), the application preferably presents 3 options to the user. The user can put the 
caller on hold, sent the caller to the voicemail of the destination, or send a NetMessage to 
the destination's computer. On the receiving end of the NetMessage, the user would see a dialog 
box on his machine with the text message and 2 options i.e. accepting the call or ignore the 
call. If the user chooses to accept the call, the call automatically transfers from the 
originated extension to the destination. If the user chooses to refuse the call, the 
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Detailed Description Text (88) : 

Referring now to FIGS. 8A to 8D, exemplary windows from illustrative preferred embodiments of 
office attendant-type programs in accordance with the present invention will now be described. 
As illustrated in FIG. 8A window 130 includes one or more line displays 132 (five are shown in 
FIG. 8A for illustrative purposes) for indicating various telephone lines available in the 
particular application of communications system 50. The number of telephone lines, of course, 
may be tailored for the particular application. Preferably positioned adjacent to line displays 
132 is call/line status display 148 for displaying symbols adjacent to each line indicative of 
the status of the line, such as idle, phone ringing, active call in progress, call on hold, 
hold recall alert, etc. Status display 148 provides a ready visual indicator to the user of the 
office attendant-type program of the status of the various telephone lines that are being 
monitored. Also adjacent to the line displays (as illustrated adjacent to status display 148) 
are user identification displays 150, which serves to display the name and/or extension or 
telephone number of one or both parties to a call. In certain embodiments, caller ID type 
information may be obtained by communications system 50 from an appropriate interface card (see 
interface cards 82 of FIG. 3) and also displayed on displays 150. Displays 150 also may display 
a clock indicating the duration of a call on a particular line. 

Detailed Description Text (95) : 

In preferred embodiments, calls may be directed to the computer running the office attendant 
type program because a main number has been directed to this computer (and its associated 
telephone or headset) , or because calls have been forwarded to the office attendant type 
program, or because a called party is on the phone, has indicated the called extension is "do 
not disturb," etc. In such situations, the office attendant type program user may need to 
transfer calls to other extensions, either inside the office or outside the office. 

Detailed Description Text (96): 

Preferably, persons in the office have a computer running a program in companion with the 
office attendant-type program. Such windows may include, for example, an animated icon, caller 
ID information, etc., and may include one or more icon the clicking of which causes the call to 
be answered. In such preferred embodiments, the office attendant type program may cause one or 
more windows to appear on the computers of particular persons in the office, such as a person 
to whom a call is being directed. As an illustrative example, a call may come in through WAN 
services network 58 (see, e.g., FIG. 3) and be directed to a main telephone number, which may 
be designated to be forwarded to a telephone associated with a person running the office 
attendant type program on a particular computer 24, and may be so directed by way of TDM bus 78 
and switch/multiplexer 74, under control of processor/system resources 70. The computer 24 
running the office attendant type program may be used to transfer the incoming call to a 
particular extension, which may be readily accomplished by way of transfer icon 178 (see FIG. 
8A) . 

Detailed Description Text (98) : 

In accordance with preferred embodiments of the present invention, in the event of a failed 
transfer, for example in case the extension to which the call is being transferred is busy, a 
window preferably is automatically displayed on the computer running the office attendant type 
program. An exemplary window 208 is illustrated in FIG. 9B. As illustrated, display 210 may 
display a descriptive message, such as "line busy," "do not disturb," etc. Preferably, a number 
of icons also are simultaneously displayed to aid the office attendant type program user in 
processing this call. Hold icon 212 may be used to place the caller on hold. Message icon 214 
may be used to initiate a net message to the party to whom the call is to be transferred. Voice 
mail icon 216 may be used to direct the call into the voice mail of the party to whom the call 
was to be transferred. Cancel icon 218 may be used to cancel the transfer operation. With such 
an automatically generated window 208, the office attendant type program user is presented with 
options to more quickly process such calls, again preferably with a single or very few clicks 
of the mouse or pointer. 

Detailed Description Text (99) : 

In certain embodiments, activation of hold icon 212 automatically "parks" the call 'on the 
extension of the party to whom the call is to be transferred. In certain embodiments, 
particular subscribers may have the option to program their extension so that calls parked on 
their extension may or may not be automatically connected once the called party has completed 
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its current call. In such embodiments, it may be desirable to have the called party informed 
that a call is being held. Preferably in such embodiments, the office attendant type program 
may be configured to automatically send a message (over a packet bus, as described earlier) to 
the computer of the party, to whom the call is to be transferred, such as is illustrated by 
window 220 in FIG. 9C. In such embodiments, window 220 may contain message box 222, which may 
contain a message such as "call holding" or "call holding from Mike at extension 226, " or "call 
holding; outside caller, number xxx, 11 etc. What is important is that message box 222 display a 
message that a call is holding, with appropriate information identifying the caller displayed 
to the extent possible or desired. It should be noted that in certain embodiments caller ID 
information is displayed, and in some such embodiments a directory or library of names or other 
identifying information may be contained in communications system 50 and/or one or more of the 
computers connected to the LAN so that names or other identifying information may be associated 
with the caller ID information and displayed in message box 222. Preferably, the computer of 
the called party plays an audible tone or sound. 

Detailed Description Text (102) : 

It should also be noted that, in the event of a particular user extension being dialed directly 
without going through the office attendant type program, a window such as window 220 of FIG. 9C 
may be displayed on the computer of the called party, either automatically for all calls, or 
only in the event that the called party has put his telephone on do not disturb, but has 
configured his extension to receive a message notification of calls, or in the event that the 
called party is on the line. In such embodiments, communications system 50 may generate such a 
window by a suitable message sent over by packet bus to the user's computer. In such 
embodiments, communications system 50 may simultaneously ring a user's extension and notify the 
user of the call with a net message, with the called being accepted, parked or forwarded to 
voice mail such as described earlier. Of course, in the event that a user previously configured 
his extension to be automatically forwarded to another extension or location or to voice mail 
or the like, then communications system preferably takes the programmed action directly. As an 
illustrative example, a user may configure his extension so as to route all calls to another 
extension or to a local or long distance telephone number. Such a user also may configure his 
extension so as to route all calls as voice over IP ("VoIP") call. In the later situation, 
processor/system resources 70 and/or DSP 76 may process the incoming voice information 
(received through the appropriate station card 82 and via TDM bus 78, etc.) into appropriate IP 
packets, which may then be routed, for example, through an HDLC f ramer/def ramer 73B, through 
switch/multiplexer 74, over TDM bus 78 and out over a designated IP connection via WAN services 
58, etc. 

Detailed Description Text (103) : 

As previously described in connection with FIGS. 8A and 9B, a user running the office attendant 
type program preferably is presented with icon 174 (FIG. 8A) and icon 214 (FIG. 9B) for 
generating net messages, such as to send a net message to a user to whom a call is to be 
transferred, or to otherwise send a net message to a particular user, etc. FIG. 10A illustrates 
window 230 as an exemplary net message window that may be generated in response to clicking 
icon 174 or 214. As illustrated, window 230 preferably includes box 232 to identify the 
recipient of the intended net message, which may be automatically selected by the office 
attendant type program in the event of a failed call transfer situation. Otherwise, the 
recipient may be selected by pull-down menu as illustrated, or by direct entry of a name or 
extension number, etc. In preferred embodiments, as letters of the name is typed, the office 
attendant type progra m automatically scrolls through the subscriber directory in order to more 
arrive at the desired net message recipient. 

Detailed Description Text (106) : 

In alternate embodiments, net messages may be sent from a computer running an office attendant- 
type program or a companion program, to any other computer coupled to communications system 50, 
either by way of the LAN or WAN, etc. In such embodiments, for example, if the user to whom a 
message is directed is logged onto communications system 50, the net message may be sent 
(preferably via communications system 50) either as a net message as previously described, or 
in the form of a visual "pink slip," "yellow sticky note," etc., which preferably appears in a 
small window on the screen of the user/message recipient. Still preferably, such "pink slip" or 
"yellow sticky note" messages include icons for options such as reply, delete, file/store, 
minimize, etc.; preferably, after a reply, delete, and/or file/store command, the message 
window automatically disappears. In certain embodiments, if a plurality of such messages are 
received and have not been processed so as to disappear, then such messages automatically stack 
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up, with a visual representation of stacked messages presented to the user (e.g., showing a 
third dimension of a stack of messages, etc.). In such embodiments, the user preferably sees 
the most recently received message on top, and also has the option to freeze/hold the updating 
of the message stack such as by selecting a suitable icon (e.g., if the user is reading a 
particular message, he/she may command that the message being read is not replaced by a 
subsequently received message), scroll through the stack of messages, etc. Still preferably, 
the user may select (again my suitable icon) that a particular message be forwarded to 
himself /herself as email, or to another person either as a similar message or email, etc. In 
preferred embodiments, communications system 50 automatically stores and sends as email all 
such messages that are not processed in a definitive manner by the user (e.g., if the user logs 
off without having replied, deleted, stored, etc. such messages, then communications system 50 
processes such unclosed messages as emails to the particular user or users, etc.). 

Detailed Description Text (109): 

As indicated, conference icon 172 may be utilized to initiate a conference call in accordance 
with the present invention. Alternatively, in other preferred embodiments the conference call 
may be initiated by a click and drag operation. For example, an icon indicating a received call 
or the status of a received call (such as described earlier) may be clicked and dragged over 
the opened dialpad (see, e.g., FIG. 8A) . The office attendant type program recognizes this 
click and drag operation as a request to open a suitable conference window, and the office 
attendant type program thereafter automatically opens the conference window. 

Detailed Description Text (111) : 

In the event that icon 264 is selected, a call others operation may be initiated. FIG. 11B 
illustrates one embodiment of window 270 for calling additional attendees. As illustrated,, 
window 270 preferably includes dialpad 272, which may be utilized to dial the extension or 
telephone number of a party to be added to the conference, which may be a party either on 
premises or off premises. Window 274 may be used to access either personal or system contact 
information, or both personal and system contact information, such as previously described. The 
names of particular subscribers may be entered or displayed in window 273, and the extension or 
number of a particular party to be added to the conference may be entered or displayed in 
window 276. Additional attendees may be added with icon 278 or removed with icon 280, with the 
additional attendees identified in window 282, with attendees in the conference identified in 
window 284. The next icon 286 preferably may be used to proceed to a dialog box from which the 
additional attendees may be called .to join the conference. Selecting the finish icon 288 
preferably results in the conference commencing or continuing without proceeding to a call 
dialog box. 

Detailed Description Text (117) : 

It also should be noted that an office attendant-type program also may be run from a location 
remote from communications system 50, such as on a computer coupled to WAN services network 58 
of FIG. 3. In such embodiments, a remote computer coupled to communications system 50 over a 
WAN network connection may run the office attendant-type program and remotely control the 
telephony functions of the office, in a manner such as described previously herein. Thus, 
control of telephony functions may be effectively performed in the office or remotely from the 
office, with control passed from computer to computer in an efficient and desired manner. 
Additionally, the user of the remote computer may run an office attendant-type program or a 
companion program as described elsewhere herein, and from such remote location be coupled to 
communications system 50 and remotely reconfigure the telephony and/or voice mail settings for 
the particular user. As an example, the remote user may use the remote computer in order to 
direct telephone calls to his/her extension to voice mail, or alternatively to have such calls 
forwarded to another extension or to a remote telephone number. With such embodiments, 
particular users may remotely access communications system 50 and, for example, control the 
forwarding of calls to an internal or remote location. As a particular example, a user using a 
notebook computer or PDA, etc., may couple to the Internet or WAN, etc. from a remote location, 
and direct that telephone calls to his/her office extension be forwarded in a desired manner 
(e.g., off-premise call forwarding, etc.). With the user able to access communications system 
50 and remotely set and store PBX-type settings remotely, a variety of desired reconfiguration 
options are presented to the user. 

Detailed Description Text (119) : 

In preferred embodiments, communications system 50 may dynamically associate physical 
telephones 12 with particular user extension numbers. In certain respect, this may be 
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considered like a "DHCP" (described elsewhere herein) for physical telephones . For example, a 
system administration may run a configuration/administration program (such as described 
elsewhere herein) and configure an extension number (e.g., 200) for a particular user, 
including associated parameters for such user, such as telephony and voice mail options (e.g., 
user forward settings, including off premise call forwarding, busy forward settings, ring-no- 
answer forward settings, time of day forward settings, display name for telephones displaying 
caller names, etc., whether the telephone is configured to be a telephone for a user running an 
office attendant-type program, etc.). At this time, the system administrator may or may not 
assign a physical telephone to that extension. Thereafter, the system administrator may notify 
the user that his/her extension number is 200. The system administrator also has the ability to 
enable and/or assign physical telephones . In the event that the system administrator has not 
assigned a physical telephone to that user, the user preferably has the ability to assign a 
physical telephone to his/her extension. For example, the user may pick up a telephone that has 
been enabled, and preferably does not have an extension assigned to that telephone, and the 
user enters a special code, e.g., numbers that communications system 50 recognizes as a request 
to assign a physical telephone . In certain embodiments, communications system 50 audibly 
informs (such as using DSP 76) the user of the status of that physical telephone (e.g., enabled 
or disabled, presently assigned to an extension, etc.). Thereafter, the user preferably is 
prompted audibly to enter his/her extension number. Optionally after a confirmation prompt, 
communications system 50 then assigns that physical telephone to the particular user. Still 
optionally, if the particular user extension is already assigned to another physical telephone, 
then communications system 50 un-assigns the other physical telephone at the time a new 
physical telephone is assigned to the particular user/user extension. 

Detailed Description Text (120) : 

As will be appreciated, with such embodiments a special code also may be provided to un-assign 
physical telephones from particular user extensions, which preferably is implemented with 
password protection for particular users to ensure that the user's extension may not be 
assigned or re-assigned to physical telephones without the user's authorization or control 
(e.g., after entry of the extension number, communications system 50 prompts the user for a 
password associated with that user extension, and only allows assignment of a physical 
telephone to that extension if the correct password is entered, etc.) . Thus, a user may assign 
his extension to a physical telephone by picking up that telephone and entering appropriate 
commands via the telephone keypad, and may un-assign his/her extension from that physical 
telephone by similarly picking up the physical telephone and entering appropriate commands via 
the telephone keypad (or by assigning the extension to a different physical telephone, as 
previously described), etc. In accordance with such embodiments, various office telephony 
arrangements may be implemented, such as an office arrangement in which a plurality of 
cubicles, offices or other physical spaces are provided with physical telephones but are not 
assigned to particular users. In accordance with such embodiments, particular users may be 
assigned an extension, and may occupy an available physical space and assign the physical 
telephone in that physical space with the user's extension. At the end of time for occupying 
that physical space, the user may un-assign his/her extension from that physical telephone, and 
then re-assign the extension to another physical telephone when the user later occupies another 
physical space, etc. 

Detailed Description Text (121) : 

Additionally, as previously described communications system 50 may serve as an email server or 
otherwise serve to distribute email to particular computers (such as computers 24) coupled to 
communications system 50. Thus, communications system 50 can store information indicating that 
a particular user or users have received email. In such embodiments, communications system 50 
preferably provides a visual or audio indication to the user that he/she has email. As 
illustrative examples, a special dial tone or message may be generated (such as with DSP 76) 
and presented to the user's telephone so that, when the user picks up his/her telephone, the 
special dial tone or message alerts the user that he/she has email (which also may include a 
special tone or message indicating that the user has voice mail) . As one example, the tone or 
message may be a particular sound, but preferably is an audible message such as "you have 
email," or "you have voice mail and email" or "you have voice mail," etc. In the event that 
communications system 50 is implemented with telephones 12 having message indicator lamps, a 
particular lamp or blinking sequence may be used to indicate that the user has email, voice 
mail or both, etc. In all such embodiments, users may be desirably informed that they have 
email and/or voice mail with their telephony device (e.g., telephone ) . 
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Detailed Description Text (122) : 

As described elsewhere herein, communications system 50 may serve to provide email services to 
particular users with telephone extensions associated with communications system 50, etc. In 
addition, communication system 50 also provides a platform (such as with processor/system 
resources 70) on which various management, administration or other types of applications may be 
run (exemplary such applications are described elsewhere herein) . In one embodiment, various 
WAN and other information is provided using an what is known as a SNMP-type protocol (as is 
known in the art, SNMP stands for Signaling Network Management Protocol, which is a 
protocol/method by which network management applications can query or request information from 
a management agent (such as are implemented in the present invention with processor/system 
resources 70 and appropriate software, etc.). A novel aspect of such embodiments of the present 
invention is that the voice mail system of communications system 50 also is implemented in a 
manner to provide voice mail related information in an SNMP-type form. Thus, in accordance with 
such embodiments of the present invention, communications system 50 stores a variety of 
information relating to voice mail, such as information relating to the status of the voice 
mail system, failure or alarm-type information, usage statistics, etc. In such embodiments, any 
tool or application that is SNMP compliant can access and view such voice-mail related 
information. Exemplary voice-mail-related information that may be made available via SNMP to an 
SNMP compliant tool or application is set forth in Table 1. With such embodiments, network (WAN 
and LAN, etc.) and PBX information along with voice mail-related information may be desirably 
provided using SNMP to a variety of SNMP tools and applications. 

Detailed Description Text (130) : 

As also described elsewhere herein, in preferred embodiments VoIP communications may be readily 
enabled. Referring again to FIG. 3, voice from a telephone 12 may be coupled via station cards 
82 and TDM bus 78 to switch/multiplexer 74. From switch/multiplexer 74, the voice data stream 
may be directed to DSP 76, which directly or in conjunction with processor/system resources 70, 
produce appropriate IP packet data (in effect, DSP 76 and/or processor/system resources 70 
serve as, for example, a TCP/IP processor) . After IP packeting, the voice data maybe directed 
to WAN services network 58 via an HDLC f ramer/def ramer 73B (such as described elsewhere 
herein) , or may be directed to one or more packet buses/LANs, also as previously described. It 
should be noted that, with DSP 76, which may be configured to provide substantial processing 
resources, voice data may be IP processed effectively with minimal or no consumption of the 
resources of computer/system resources 70, thereby helping to prevent an undesirable loading of 
computer/systems resources 70. 

Detailed Description Text (148): 

The multiple-bus architecture, application prioritization and isolation, and automatic route 
selection adds to the performance of communication system 50. These features ensure high-grade 
voice quality by keeping voice and data in their native environments, allow conversion between 
the voice and data environments to support services such as voice over IP (VoIP) , maximize 
investment by making community resources, such as DSPs and WAN/ LAN interfaces, available to 
both voice and data applications, keep mission-critical communications systems functioning 
under heavy load by ensuring they receive required system resources, provide flexibility in 
routing calls, and least-cost routing saves money by dynamically selecting trunks based on 
criteria selected. 

Detailed Description Text (155) : 

The PBX capabilities will now be described. Communications system 50 PBX provides a full- 
featured, nonblocking digital PBX with sophisticated call control capabilities. These 
capabilities are delivered using standard analog telephones connected to your existing phone 
wiring. In addition, communications system 50 supports advanced call control capabilities over 
IP-based networks, for applications based on the Microsoft Telephony Application Programming 
Interface (TAPI) standard. TAPI allows the communication system 50 to optionally provide 
virtual digital telephones, delivering advanced call control features over inexpensive standard 
analog phones. 

Detailed Description Text (161): 

Communications system 50 PBX and Office attendant type program specifications are now shown 
below. PBX features for call features include the following: Call forwarding, Off -premise call 
forwarding, Transfer on busy and no answer, Time-of-day call forwarding, Call hold, Call 
toggle, Call waiting, Consultation call, Consultation transfer, Blind transfer, Conference 
call, Call pickup, Public address system support, and Do not disturb. The features for calling 
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and called party identification are as follows: support for enhanced caller ID phones, and 
Extension-to-extension identification. 

Detailed Description Text (163) : 

The following are the office attendant type program features: (1) System — Standard Windows 
application; Call control over IP; Software-based console that is easy to relocate; Drag-and- 
drop dialing and conferencing; Virtual line appearances; Interface indicators signal call 
status; Caller ID display; Calls in queue display; Company telephone directory; Lookup-as-you- 
type dialing; Personal call log; Account number entry; Personal information manager; Conference 
manager; System speed-dial buttons; Programmable feature buttons; Most recently used numbers 
list; Login security; CTI link test button; Context-sensitive help; and Contact database 
importing; (2) Call handling — Dial pad; Hang up; Transfer with look-ahead; Hold; Answer next; 
Call forwarding; Do not disturb; (3) Installation requirements — 66-MHz 486 PC with 16 MB of RAM 
(Pentium recommended); and Windows 95 or Windows NT 4.0. 

Detailed Description Text (167) : 

The Communications system 50 AutoAttendant application economically processes inbound calls 24 
hours a day — answering each call, providing customized instructions based on the time of day or 
day of week, and routing callers to the person best able to help them. Callers can use the 
intelligent call distribution feature to reach a particular person or department, without 
requiring an operator or direct inward dial (DID) services. For companies that use DID, 
AutoAttendant is ideally suited for assisting a live operator by handling common requests for 
information such as directions and mailing addresses . 

Detailed Description Text (180) : 

Communications system 50 Remote Management System addresses these cost-of-ownership issues by 
providing integrated remote management capabilities for both voice and data services. Designed 
for remote management and fault monitoring, the Remote Management System provides a cost- 
effective method for managing the entire customer premise remotely. Companies with multiple 
offices or plans to expand can realize significant cost savings by leveraging their expensive 
technical resources, no matter where they are located. Furthermore, the centralized management 
capabilities of communications system 50 present a unique managed network service opportunity 
for both voice and data service providers. 

Detailed Description Text (188) : 

Referring now to FIG. 14, additional preferred embodiments utilizing advanced call logging 
features will now be described. As illustrated in FIG. 14, call logging window 350 may be 
opened by a user of an office attendant-type program running on a computer in accordance with 
the present invention (see, e.g., FIG. 8A, call log icon 142). In alternative embodiments, call 
logging window 350 may be automatically opened upon receipt of an incoming call, or upon 
initiation of an outgoing call. Window 350 preferably includes display windows 352 and 354, 
which preferably displays information for calls in the log, such as a call log identification 
number, begin call time, end call time, duration of call, type of call (either inbound or 
outbound), account information, etc. In other embodiments, other information desired to be 
included in a call log record is included in such a window. Window 354 is illustrated with only 
one call displayed, although it should be understood that a plurality of calls my be displayed 
in window 354, and in fact the call log can include numerous calls that cannot be displayed 
simultaneously in window 354. A scroll button or buttons (such as scroll icon 353) preferably 
are provided to scroll up and/or down the logged calls. 

Detailed Description Text (190) : 

In certain embodiments, upon receipt of an incoming call or upon initiation of an outgoing 
call, a window such as window 350 automatically appears (this may be by way of the office 
attendant-type program for a user who is managing incoming and outgoing calls of the office, or 
by way of a companion program for a user not managing incoming and outgoing calls of the 
office) . In preferred embodiments, the user is prompted by a brief message displayed on the 
screen and/or an audio message played on the user's computer to enter the account number in 
window/field 358. In still other embodiments, the user must insert an account number in 
window/ field 358 in order to complete the incoming or outgoing call. In such embodiments, 
processor/system resources 70 and/or the user's computer promptly reads any account number 
information provided by the user and any accepts or validates the account number (e.g., 
compares the entered account number to a stored list of valid account numbers, and determines 
if there is a match) . In the event that an invalid account number is detected, a suitable 
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message window and/or audio alert indicating that the account number entered is invalid, 
unrecognized, etc:, preferably is provided to the user. In the event that a valid account 
number is detected, then the call is completed. 

Detailed Description Text (192) : 

In still alternate embodiments, communications system 50 (and/or another computer coupled to 
communications system 50 via a packet bus, etc.), periodically polls the computers utilizing a 
program with a call logging such as previously described retrieves the call log information. 
With automated call log polling, a central resource such as communications system 50 (and/or 
another computer) may periodically, and preferably automatically, collect call logging 
information over the packet bus (again, see, e.g., FIG. 3), which may be then made available to 
a suitable application running on communications system 50 and/or another computer, and 
compiled, processed, analyzed, printed, etc. In accordance with such embodiments, incoming and 
outgoing calls may be desirably logged and associated with account information, with such 
logged information desirably collected from a plurality of computers and made available to a 
central resource for further processing and/or use. 

Detailed Description Text (221) : 

It should be noted that communications systems 50 illustrated in FIGS . 18 and 19, for example, 
also have coupled thereto a plurality of computers, telephones, etc., as previously described 
for purposes of generating, receiving various data streams, etc., although such details have 
not been shown for ease of description. 

Detailed Description Text (222) : 

As described elsewhere herein, various voice mail type options may be presented to users of 
such communications systems in accordance with the present invention. One such advantageous 
voice mail option provided in accordance with preferred embodiments of the present invention 
include advanced email or voice mail-type broadcasts of desired messages. A user may decide to 
send a voice mail or email to some or all users of the communication system. With a suitable 
office attendant-type or companion-type program, for example, a user may select from a group 
list, etc., a desired group of persons to receive the communication. A broadcast voice mail, 
for example, could be input through the user's telephone in a conventional manner, and routed 
(see FIG. 3) through, for example, DSP 78 (via TDM bus 78, switch/multiplexer 74, etc.) which 
converts the voice mail message into an suitable data format, such as what is known as a WAV 
file, etc., and then sent via (for example) packet bus 80A and/or 80B to a plurality of 
computers. Communications system 50 also, for example, can record which users have received or 
not received the communication so that users may later receive the communication (such as when 
they log on at a later time) . In addition, communications system 50 also has the capability to 
parallely process the communication as a message that is to be sent to persons via, for example 
the Internet. Using an HDLC f ramer/def ramer as is provided in accordance with the present 
invention, a user may generate a voice mail or email communication that the communications 
system sends as packetized data over the LAN to recipients recognized to be users having a 
computer on the LAN, while generating a suitable HDLC, ATM framed communication to recipients 
who are reachable over the WAN, such as over the Internet or other IP connection, etc. 

Detailed Description Text (225) : 

It also should be noted that, in preferred embodiments, DSP 76 is coupled to switch/multiplexer 
74 in a manner so that it may "tap" into the various TDM data streams. This provides a 
significant improvement over systems in which data streams must be directed into a resource 
such as DSP 76, and then sent from DSP 76 over a separate channel, etc. (thereby utilized two 
channels, etc.). In such embodiments, DSP 76 can tap into or monitor data streams on particular 
TDM channels and provide, for example, processing to accomplish recognition (voice or speech, 
etc.), detection (such as of a fax or modem call, etc.), compression (including compression, 
transcoding, streaming and storing, etc.), packetizing (such as to prepare a data format such 
as for an email, etc.). In one illustrative example of such embodiments, communications system 
50 may be programmed so that particular users (e.g., president, technical support, warranty 
claims line, etc.) automatically have voice mails stored as voice mails and also as an email or 
other data form. Thus, a voice call may be directed into voice mail, while DSP 76 concurrently 
processes the voice data stream into another form (e.g., email, data file, etc.), which may be 
stored, send over the WAN or LAN, etc. Having DSP 76, and particularly configured (such as with 
switch/multiplexer 74) so as to tap into the various channels, provides significant advantages 
in a variety of applications. 
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Detailed Description Text (228) : 

Backup communications module 416 preferably includes bus interface 420 for coupling information 
to/from bus 414, memory 424 for storing various information, as will described hereinafter, CPU 
418, FLASH or other programmable memory 426, and modem or other . communication unit 428. Module 
416 preferably includes a standby or backup power supply 434, although in certain alternate 
embodiments communication unit 428 is coupled to, for example, link 430 of WAN services 58E, 
which may be a dedicated telephone line, POTS line, etc., which provides sufficient power to 
module 416 so that power supply 434 is not required. In such alternate embodiments, the various 
components of module 416 are implemented in low power CMOS technology or the like, and consume 
sufficiently low amounts of power so that module 434 may operate at a suitable speed in order 
to provide backup communications using only the power provided by link 430, such as, for 
example, in the event of a power failure in communications system 50 or the office in which 
communications system 50 is located, etc. 

Detailed Description Text (233) : 

As previously described, module 416 preferably has a dedicate line (e.g., a POTS line) for such 
backup communications, and telephone 12 optionally may be coupled to such line for emergency 
voice calls or the like, etc. In alternate embodiments, however, communications unit is also 
(or alternatively) coupled to channels of TDM bus 78. In certain embodiments, a predetermined 
channel or channels of TDM bus 78 are dedicated for such backup communications. In other 
embodiments, communication unit 428 is coupled to TDM bus 78 through switch 432, and in such 
embodiments dedicated TDM channels are not required. 

Detailed Description Text (236) : 

Referring now to FIGS. 25 to 35, exemplary embodiments of programmable digital telephones 
coupled to communications system 5 0 and an accompanying GUI configuration will be described. 

Detailed Description Text (237): 

FIGS. 25 to 29 illustrate preferred embodiments of the physical design of four programmable 
digital telephones . FIG. 25 illustrates 8-button telephone 466. FIG. 19 illustrates 8-button 
telephone 468 with display. FIG. 20 illustrates 16-button telephone 470 and FIG. 21 illustrates 
64-button telephone 472. Preferably each digital telephone can be programmed individually 
through a series of GUI windows in the user configuration module, to which will be described 
below. 

Detailed Description Text (238) : 

FIG. 29 depicts exemplary embodiments of the digital telephones in further detail, illustrating 
the physical features that preferably accompany each telephone set. Preferably each telephone 
consists of telephone chassis 474, handset 476, display 478, feature keys 480, feature key LEDs 
482, dial pad 484, speaker 486, volume control keys 488, and microphone jack 490. In preferred 
embodiments of the digital telephones, the features include tri-colored LEDs, wherein each 
color corresponds to one of three states (on, off, or flash) and indicates the state of each 
line key, such as idle, dial, ring, connect, block, hold, bypass, etc. It should be appreciated 
that in alternate embodiments, the physical features may include additional LEDs, buttons, 
speakers, microphones, switches, jacks, ports, antennas, card slots, and cardbuses, etc. 

Detailed Description Text (239) : 

The digital telephones preferably provide the following pre-programmed features: (1) Idle: When 
two telephones are connected, and the user disconnects and returns to idle, the second 
telephone also returns to idle, so that it is unnecessary for the user to hang up the handset 
or press release. (2) Hold: To place the current call on hold and answer the call waiting call, 
the user may press the call waiting button. The primary line LED may flash (e.g.: red) and the 
call waiting LED may be lit and connected (e.g.: green). To place the call waiting on hold and 
switch back to the original call, the user presses the primary line key. This feature of 
toggling back and forth between the two calls can continue as many times as desired. (3) Hot 
dial pad: While the telephone is idle, the user may press a digit to automatically place the 
telephone in handsfree mode and initiate a dialing sequence. When the last digit is dialed, 
then the call is placed. The call may be switched to the handset at any time by lifting the 
handset. (4) Autodial: Pressing the 1 key while the telephone is idle automatically puts the 
telephone in handsfree mode and dials the number programmed into the autodial button, thus 
placing the call. The call progress tones are audible through the speaker. The call may be 
switched to the handset at any time by lifting the handset. (5) Message waiting: The message 
waiting indicator doubles as an easily accessible way to call and access voicemail. The user 
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presses the MWI key while telephone is idle, which automatically places the telephone in the 
handsfree mode and accesses voicemail. (6) Conference call: For a conference call, the user 
establishes a connection with the first party, either by receiving or making a call, then 
presses the conference button and dials the second party. After the call is answered, the user 
presses the conference button again. The display updates on the telephone on each connected 
party to show there are three members in the conference. To add a fourth party, the user may 
repeat these steps, starting with pressing the conference button. (7) Transfer: To transfer a 
call that is presently connected, the user preferably presses transfer and dial the target 
extension, waits for the answer, then presses the transfer button again. If the user wishes to 
perform a blind transfer, then the user presses the transfer button again while the call is 
still ringing. (8) Blind transfer: If the user frequently does blind transfers, the transfer 
button may be programmed to always perform a blind transfer. In this case, the second push of 
the transfer button is unnecessary. (9) Call waiting: For call waiting, a call to an extension 
while connected in another call will show as ringing on the call waiting button. The call 
waiting button is then treated as a pseudo-line key. 

Detailed Description- Text (240) : 

Referring to FIG. 30, preferred embodiments of the GUI configuration of the programmable 
digital telephones will now be described. It should be understood that such a configuration 
application may be run any computer connected to communication system 50, similar to the 
configuration windows described elsewhere herein. Thus, in addition to programming features and 
buttons of such digital phones with telephone keypad depressions (with the digital phone put in 
a program mode that conveys phone configuration information to communication system 50 such as 
by commands sent via the telephone ) , such a graphical interface may more desirably guide a user 
through the steps of programming the digital phones, with the configuration data resulting from 
the configuration send to communication system 50 such as over a packet bus as previously 
described. 

Detailed Description Text (241) : 

As illustrated in FIG. 30, configure user window 492 is provided to configure feature keys 480 
of digital telephones 466 to 472. Configure user window 492 may be opened by a user or 
administration of an office attendant-type program or remote configuration-type program running 
on a computer coupled to communication system 50. Window 492 preferably includes user name 
display 494, extension display 496, OK button 498, cancel button 500, help button 502, and 
tabbed windows 504, such as overview, telephone, forwarding, pickup group, etc. To program the 
digital telephones, the user preferably selects the tabbed window labeled telephone, whereupon 
telephone window 5 06 will appear. 

Detailed Description Text (242) : 

FIG. 31 illustrates telephone window 506, which is provided for identifying the features of 
digital telephones 466 to 472. As noted in telephone window 506, the user is instructed to 
select the telephone type from a predetermined list of telephone types, which may be limited by 
the hardware of the slot or port. The list of telephone types appears in pulldown menu 508. The 
user preferably selects radial button 510 to enable or disable the supported digital telephone . 
The user may also select the types of features from a predetermined list of templates in 
pulldown menu 512, which are determined by the type of digital telephone selected by the user. 
After the user selects a feature from pulldown menu 512, the user may select customize button 
514 to modify the programmable fields for the feature key settings on the selected digital 
telephone . Additional features, such as call waiting and do not disturb, are noted with 
checkboxes 516, in the features section of telephone window 506. FIG. 32 further illustrates 
pulldown menu 512, which preferably includes a plurality of features, such as basic, DSS/BLF, 
retail, secretarial, etc. In accordance with the present invention, data for configuring 
digital telephones 466-472, which has been selected and/or entered by the user, is saved in 
communication system 50. Communication system 50 stores configuration data for the particular 
programmed digital phone, which is then later accessed as the phone is utilized in order for 
communication system 50 to decode the button depressions on the digital phone and to take 
appropriate action in response thereto. 

Detailed Description Text (243) : 

With reference to FIG. 33, after customize button 514 is selected by the user, telephone button 
window 516 appears, displaying a digital image of the selected telephone, such as 16-button 
telephone 470. (The selected telephone will correspond to the type of telephone chosen by the 
user in pulldown menu 508 as illustrated in FIG. 31.) Telephone button window 516 provides 
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programmable fields for each feature key of digital telephones 466-472. By selecting a key in 
the GUI , the user may choose from a predetermined list of features provided in telephone button 
window 518. Accordingly, data for configuring digital telephones 466-472, which has been 
selected and/or entered by the user, is accordingly saved in communication system 50. 

Detailed Description Text (244) : 

As illustrated in FIG. 34, telephone button window 518 preferably includes customizable pop-up 
menu 520, which indicates the various programmable features available for the digital 
telephones . Preferably pop-up menu 520 is positioned adjacent to feature keys 480. The 
programmable features, for example, may include auto dial 522, call return 524, call waiting 
526, camp-on 528, Centrex flash 530, Designated station select/busy lamp field 532, do not 
disturb 534, extension pickup 536, line appearance 538, program 540, self park 542, transfer 
544, unassigned 546, user forward 548, and voice call 550. 

Detailed Description Text (245) : 

In accordance with preferred embodiments of the present invention, auto dial 522 is provided to 
automatically dial a pre-conf igured telephone number. Call return 524 rings back the extension 
of the last inbound call, if the call originated within the office attendant-type system. Call 
waiting 526 places an existing call on hold in order to connect to an incoming call. Camp-on 
528 is similar to call return 526, but provides the option of ringing back an extension as soon 
as the extension becomes available. Centrex flash 530 accesses call transfer features provided 
by Centrex telephone services, which is available through most TSPs. Designated station 
select/busy lamp field (or DSS/BLF) 532 monitors the status of specified extensions and 
transfers calls to those extensions. Do not disturb 534 prevents a telephone from ringing. 
Extension pickup 536 answers a specific ringing extension within a call pickup group. Line 
appearance 538 is a secondary line for extensions without a designated station port or a 
physical telephone ; it provides a voicemail rollover function for either primary or virtual 
extensions. Program 540 enables programmable features, such as auto dial, forward, and 
voicecall keys. Self park 542 places a call in a parked state on the user telephone for 
retrieval from another telephone . Transfer 544 transfers calls to another extension. Unassigned 
546 provides the option of leaving the extension unassigned. User forward 548 dispatches calls 
to another extension or telephone number. Voicecall 550 enables an intercom to page a specific 
extension. It is important to note that some of these programmable features may be selected and 
used simultaneously, depending upon which features are enabled and disabled. 

Detailed Description Text (246) : 

As further illustrated in FIG. 34, if a feature is selected in telephone button window 518, 
then the feature preferably is highlighted as exemplified by DSS/BLF 532. The user then 
preferably presses OK button 552 to make the selection or cancel button 554 to cancel the 
selection. However, if a feature is selected, then configuration window 556 appears as 
illustrated in FIG. 35. Accordingly, data for configuring digital telephones 466-472, which has 
been selected and/or entered by the user, is accordingly saved in communication system 50. 

Detailed Description Text (248) : 

As illustrated in FIG. 36, additional settings window 561 preferably includes one or a 
plurality of check boxes for optional features, such as do not ring telephone, do not receive 
paging, use off hook ring, mute microphone when voice calls are received, etc. In accordance 
with the present invention, data for configuring digital telephones 466-472, which has been 
selected and/or entered by the user, is accordingly saved in communication system 50. 

Detailed Description Text (249) : 

In addition, similar GUI configuration windows preferably are provided in order to facilitate 
production of labels that are typically applied to the digital phone in order to provide a 
visual indication of the particular functions that have been programmed for the particular 
buttons of the phone, etc. Preferably, an application runs in conjunction with the phone 
configuration application, which automatically prints labels for the feature keys in accordance 
with the programmable fields selected for a specified digital telephone . In a preferred 
embodiment of the present invention, data about programmable fields generated as part of the 
phone configuration process are stored in one or more files that are accessible by the label 
generation application. Such files preferably extract the configuration data, associate it with 
particular buttons of the particular phone that was configured, with the application preparing 
a label that corresponds to the particular programmed features for the particular programmed 
phone. Thus, the label generation application may use this data to print programmable field 
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information (e.g. redial, hold, voice call, etc.) on preferably pre-f ormatted labels which 
correspond to the type of digital telephone and the selected feature keys of feature keys 480. 
Labels may be printed in a plurality of formats of generic telephone labels and in accordance 
with the programmable features and types of digital telephones . For example, a user may print 
pre-formatted labels for 16-button telephone 470, so that the pre-f ormatted labels correspond 
to feature keys 480 on 16-button telephone 470. Label generation window preferably provides the 
user with step-by-step instructions for printing labels via a series of linked windows. It is 
important to note that the label generation window also preferably provides a one-click button 
for printing labels, so that a button in the label generation window may be pressed by the user 
to print the feature key label. Thus, a computer, such as computer 24 in FIG. 3, when coupled 
to communication system 50, may print digital telephone labels via a printer, such as printer 
22 in FIG. 3. In accordance with the present invention, data for configuring digital telephones 
466-472, which has been selected and/or entered by the user, is accordingly saved by 
communication system 50. 

Detailed Description Text (251) : 

In accordance with embodiments of the present invention, a variety of highly integrated voice, 
data, and video communications systems may also be employed. In accordance with additional 
aspects of the present invention, highly advantageous methods for administering call control 
and management also are provided, including for Voice over Internet Protocol ("VoIP 11 ) type 
telephone calls. 

Detailed Description Text (252) : 

In accordance with the present invention, an administrator may more optimally control calls 
made by or to the system in accordance with what herein is referred to as a dialing plan. In 
particular, the dialing plan in accordance with preferred embodiments of the present invention 
will provide for improved control over routing of outbound calls. In accordance with preferred 
embodiments, the dialing plan will provide VoIP call support; global permission and 
restrictions via a global access profile; area code tables with support for office code ranges; 
multifunctional route tables, including destination routing, time of day routing; multiple 
trunk group queuing; trunk overflow; digit Translation; and unified dialing for off-premise 
extensions (Off-Premise Extension Table) . 

Detailed Description Text (254) : 

In preferred embodiments, the access profile (or trunk access profile) may be administered 
through an administration screen, which preferably is accessed through an Automatic Route 
Selection ("ARS") screen. In preferred embodiments, access profiles may be edited, created, 
deleted or copied to other profiles, and extensions are assigned an access profile to specify 
dialing capabilities for the extensions. Instead of routing to a specific trunk group based on 
the initial check of the access profile, in accordance with such embodiments system 
administrators will now be about to direct an outgoing call through various filters. Once the 
filtering has been completed, the call can be either sent to a single trunk group or sent to a 
specific routing table with a number of possible steps to be executed. 

Detailed Description Text (255) : 

In such preferred embodiments, there are a number of dialing area tables for dialing area 
control. In certain embodiments, three dialing area tables are provided, namely an area code 
table(s), international country code table, and a trunk group access codes table. Such tables 
are implemented to give the administrator-type person the ability to control where a user may 
or may not call. In such embodiments, routing tables are used to control access to trunk 
resources. A call which is being routed via a specific route table prevents the caller from 
using resources not accessed via the access profile. In preferred embodiments, such routing 
tables contain the same redundant profile field, but the purpose here is different. In a 
routing table, a customer uses the trunk access profile to control resources. For example, a 
user may be allowed to dial a distant area as defined in the area code table, but is restricted 
to only using the least expensive trunk group in the routing table. Such use of trunk access 
profiles may be utilized to desirably control access to and use of various telecommunications 
resources . 

Detailed Description Text (256) : 

Preferably, a screen is provided for "Local Area Codes ". Such a local area code table 
preferably contains: a Home Area Code — 7-digit local calls are routed as if this area code was 
dialed; and a Local Area Code List — Area codes that are treated as local calls. Preferably such 
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local area codes include area codes not requiring 1+dialing and area codes requiring 1+dialing. 
Thus, in accordance with the present invention the local area codes table may be accessed so 
that calls may be more intelligently controlled and managed (e.g., in order to avoid treating 
non-toll local calls as long distance calls, even though the local calls are dialed with 1+10 
digit dialing like traditional long distance calls) . 

Detailed Description Text (258) : 

FIG. 37 illustrates Automatic Route Selection ( "ARS" ) window 570 used in preferred embodiments 
of the present invention. As illustrated, ARS window 570 preferably includes display 572, which 
displays for the administrator a list of current access profiles in the system. The use of such 
access profiles is described in greater detail elsewhere herein. ARS window 570 also preferably 
provides button 574 (selectable with a mouse or pointer, etc.) that may be selected to edit 
global access profiles. Button 574 is used to add, modify or edit global access settings that 
preferably are applied to all stations/incoming trunks when an outgoing/tandem (ARS) call is 
made. As illustrated, window 570 also may include buttons to edit access profiles, add new 
access profiles, delete access profiles, copy an access profile to another access profile, 
restore (i.e., ignore changes), apply changes, complete (done) the access to window 570 or to 
access on-line help information. 

Detailed Description Text (259) : 

Further aspects of global access profiles will now be described. Global access profiles in 
accordance with the present invention may be considered an enhancement of an emergency trunk 
access profile. Entries in the global access profile, in effect, override the dialing 
extension's configured access profile. In preferred embodiment, the global access table 
contains three tabs (FIGS. 38A-C) . The special digits table (FIG. 38A) , in preferred 
embodiments, is the first table checked for outgoing ARS calls. The special digits table allows 
the administrator to route or block a call based on the initial sequence of digits. The area 
code table (FIG. 38B) , in preferred embodiments, is the second table checked for outgoing ARS 
calls. The area code table is more specialized than the special digits table (need more 
description) . The off-premise extension table (FIG. 38C) preferably contains routing 
information for extensions located in another PBX/system connected to the extension (e.g., two 
such systems connected together, either in the same office or location or in geographically 
removed offices or locations. The extension range in the off-premise extension table preferably 
conforms to the first digit table in the particular system. Such tables will now be further 
described. 

Detailed Description Text (261) : 

An exemplary area code table is shown in FIG. 38B. The area code tables preferably are 
expandable tables for handling North American Numbering Plan (NANP) numbers. An area code table 
is preferably accessed via an access profile screen. Every specific profile preferably has an 
associated area code table. The area code field preferably is a list field. All NANP area codes 
can be listed here, including an entry for unspecified (default) area codes (i.e., area codes 
added to the NANP, which were not known when the area code table was created) . As for the 
office code range field, if the dialed number needs to have a more granular examination, then 
the office code range should be entered in this field. The routing table field specifies the 
routing table used to send the dialed number out on a trunk. If set to blocked, then the area 
code is not allowed for the specific profile and the user preferably will hear fast busy. 

Detailed Description Text (263) : 

As previously described, preferred embodiments utilize an access profile to desirably assist in 
controlling/managing calls in the system. FIGS. 39A-C illustrate windows that preferably are 
used to manage access profiles. The preferred access profile screen desirably allows the 
administrator to configure permissions/restrictions for users assigned to the particular access 
profile. The access profile is used for calls which do not match any of the settings in the 
global access profile (a match in the global access profile results in the call being routed, 
intercepted, blocked, etc., as directed by the global access profile table). As illustrated in 
FIGS. 39A-C, the preferred access profile window contains three tabs; an area code table (all 
ARS calls preferably are checked in this table); a privileges table (such as international and 
carrier access calls, which typically include predetermined initial digits for specifying a 
particular carrier, such lOlOxxx-type carrier access calls); and a trunk group access codes 
table (which preferably is a permission table for using non-ARS trunk group access codes) . 
These access profile windows/ tables will now be further described. 
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Detailed Description Text (264) : 

FIG. 39A illustrates a preferred area code table for access profiles in accordance with the 
present invention. The area code tables preferably are expandable tables for handling North 
American Numbering Plan (NANP) numbers. An area code table is accessed via the access profile 
screen by selection of the appropriate tab. Every profile has an associated area code table. In 
preferred embodiments, area code tables are not shared by profiles. 

Detailed Description Text (265) : 

As illustrated in FIG. 39A, an area code field is provided. The area code field is a list 
field. All NANP area codes may be listed here, and it may include an entry for unspecified 
(default) area codes (i.e. area codes added to the NANP, which were not known when the area 
code table was created.) An office code range also is preferably provided. If the dialed number 
needs to have a more granular examination than just the area code, then an office code or code 
range may be entered in this field. A routing table also is provided. The route table field 
preferably specifies the route table that will be used to send the dialed number out on a 
trunk. If set to blocked, then the area code is not allowed for the profile and the user will 
hear fast busy (or be provided some other indicia that the call is blocked, such as described 
elsewhere herein) . 

Detailed Description Text (270) : 

Also in accordance with such embodiments, a first digit table is provided to facilitate 
desirable call control and management in accordance with the' present invention. As is known in 
the art, first digit tables are utilized to process and control calls by way of analyzing first 
digits dialed, for example, by a user depressing keys on a telephone . In accordance with such 
embodiments of the present invention, the first digit table is improved in order to more 
desirably support unified dialing plans and an increased number of trunk access codes as 
described herein. In addition, since the extension range of the off-premise extension table 
will follow the first digit table and reflect the extension range of the distant system/PBX, 
the first digit table preferably supports multiple extension lengths; e.g., first digit 3 may 
have an extension length of three, while first digit 4 may have an extension length of five, 
etc. Also in accordance with such. embodiments, first digits preferably do not serve to 
designate as "off-premise." 

Detailed Description Text (272) : 

As illustrated in FIG. 41, the first digit table may include, for example, a first digit tab, 
which may include first digit/types for attendant, extension, external, or not configured, 
etc., as illustrated. The attendant first digit/type preferably directs calls to the operator 
or attendant, whether automated or in person. The extension first digit/type are configured as 
extensions, which digits collected in accordance with the extension dialing rules, and then 
appropriately routed. An external digit/type designates a trunk access/NANP digit. Other fields 
applicable for external calls include the access code, which in preferred embodiments may be a 
one or two digit access code. The routing field, may include a <Trunk Group> (such as Tl, voice 
digital, voice analog, etc.) designation, where the call will be routed to the specified trunk 
group. The routing filed may state "not configured," indicating that the access code is not 
defined (a user dialing this access code preferably will hear fast busy or otherwise be 
provided with some indication that the access code is not defined, as discussed elsewhere 
herein). If the trunk field is designated "outbound routing," the call will be routed through 
an ARS process as discussed elsewhere herein. If the trunk field is designated "outbound 
routing, the collect digits field is automatically set to NANP. The collect digits field 
specifies the maximum number of digits to collect after the access code has been entered. If 
this field is set to NANP, then the North American Numbering Plan is used to determine the 
number of digits to collect. In preferred embodiments, entering a number in this field allows 
the caller to indicate he/she has finished dialing using the key or .letting interdigit- 

timing to expire. The dialtone field indicates whether or not dialtone is sent after the access 
code is received. In preferred embodiments, dialtone will remain until the next digit is 
received; if expected digits is set to the same length as the length of the access code, dial 
tone will not be sent. 

Detailed Description Text (273) : 

FIG. 42 illustrates a local area codes screen that may be accessed with a tab from the first 
digit table window. The local area codes screen preferably is used for setting the home area 
code and dialable local area codes . In accordance with preferred embodiments, area codes may be 
listed as "l+Area Code" or "Area Code Only." An " Area Code Only" designation allows a user to 
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dial the specified area code in a 10-digit number without requiring the user to dial "1" first. 
A "l+Area Code" causes 11-digit calls with the specified area code to be designated as local 
calls. In accordance with such embodiments, an administrator periodically checks local 
requirements to determine which format is appropriate for the particular dialing area. 
Preferably, both formats are possible within the same system/PBX. 

Detailed Description Text (278) : 

Other aspects of caller ID functionality that are included in certain embodiments of the 
invention include the following. For automatic call distribution ("ACD") applications, such as 
a software application that runs on the system (such as described elsewhere herein) that 
processes calls in a manner to distribute/forward the calls based on caller inputs, such as 
digits selecting particular departments, caller account number or identifying numbers, etc., 
voice mail or pager applications, such are preferably mapped to connected to system ports (like 
a system extension) . As system ports, ACD, voice mail, and pager numbers/applications 
preferably also have caller IDs associated with them. In preferred embodiments, for internal 
calls, the caller ID for such system ports preferably is the name and number associated with 
the group in which they belong; for external calls, the caller ID preferably is the company 
name and number. In addition, function codes may be entered to, for example, activate or block 
caller ID for particular calls (such as by dialing *67) . In preferred embodiments, regardless 
of settings, calls to 911 or similar emergency type or special calls (e.g., operator) are not 
blocked, regardless of system settings. 

Detailed Description Text (281) : 

VoIP functionality in accordance with such embodiments preferably provide a predetermined 
number of IP voice channels, for example up to eight or more channels of IP voice. Preferably, 
such embodiments provide dynamic support for both H.323 and Media Gateway Control Protocol 
(MGCP) call-control signaling. Unlike systems with an external gateway between a PBX and a data 
router, the integrated solution of preferred embodiments of the present invention provide 
direct conversions between attached telephones and IP trunks without requiring a configuration 
of several devices. To further enhance voice quality, embodiments of the present invention also 
preferably include dynamically adjustable jitter buffers, packet-loss correction, and noise- 
level matching. For greater reliability, traffic can be rerouted over alternative networks if 
there is a failure to connect over the primary route. 

Detailed Description Text (282) : 

In accordance with such embodiments, and as discussed more fully elsewhere herein, a more 
consistent user experience is provided with a single, integrated dialing plan for both circuit- 
and packet-switched voice calls. For example, employees at a branch office may contact co- 
workers at any other location by simply dialing their extension. The uniform dialing plan 
simplifies a company's migration to VoIP, since administrators can easily configure calls over 
any type of connection. With uniform dialing, such embodiments may utilize VoIP calling, when 
available, in a manner that is transparent to end users. Thus, in accordance with such 
embodiments, in a headquarters-branch office (s) arrangement, separate access trunks for voice 
and data do not need to be deployed at each site. Low-cost VoIP calling between, for example, a 
headquarters site and a branch office, and employees may use the same phones and dialing plans 
they are accustomed to, and the system automatically converts interoffice calls to VoIP calls 
if available, and if not can route the calls in a manner transparent to end users through 
alternative routing. Such systems may support simultaneous interfaces to both packet- and 
circuit-switched networks for voice calling, and least-cost routing may be automatically 
enabled for both IP and traditional voice trunks. In accordance with the present invention, 
using a packet-optimized WAN for telephony transport may significantly reduce costs by sharing 
expensive WAN bandwidth with data transmissions. Also in accordance with such embodiments, low- 
bandwidth coder-decoders (CODECS) and silence suppressors can be used to yield, for example, an 
8:1 bandwidth savings over standard circuit-switched voice calls. 

Detailed Description Text (288): 

The H.323 standard, in general, specifies four types of components that may be networked 
together to provide point-to-point and point-to-multipoint multimedia-communications services — 
terminals, gateways, gatekeepers and multipoint control units. H.323 terminals generally are 
used for real-time bi-directional multimedia communications. An H.323 terminal can either be a 
PC or a standalone device (which could be conference or other telephone or video conferencing 
unit, such as described elsewhere herein), which is running an H.323 application and the 
multimedia/communication application (s ) . In accordance with preferred embodiments, the H.323 
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terminal provides audio communications while optionally supporting video or data 
communications. An H.323 gateway provides connectivity between an H.323 network and a non-H.323 
network. For example, such a gateway can connect and provide communication between an H.323 
terminal and the PSTN. This connectivity of dissimilar networks is achieved by translating 
protocols for call setup and release, converting media formats between different networks, and 
transferring information between the networks connected by the gateway. While a gateway is not 
required, however, for communication between two terminals on an H.323 network, systems in 
accordance with preferred embodiments provide software/hardware resources to enable the system 
to serve as an H.323 gateway. A gatekeeper can be considered the brain or intelligence of an 
H.323 network. Although not required, gatekeepers provide desirable services such as 
addressing, authorization and authentication of terminals and gateways, bandwidth management, 
accounting, billing, charging and call routing-type services. Preferred embodiments of the 
present invention desirably work with an external H.323 gatekeeper, or in alternative 
embodiments also integrate/provide software/hardware resources to enable the system to serve as 
an H.323 gatekeeper. Multipoint control units (MCUs) provide support for conferences of three 
or more H.323 terminals. All terminals participating in the conference preferably establish a 
connection with the MCU, and the MCU manages conference resources, negotiates between terminals 
for the purpose of determining the audio or video CODEC that will be used, and may handle the 
media stream. While gatekeepers, gateways and MCUs typically are considered logically separate 
components of the H.323 standard, in preferred embodiments various of these components are 
integrated or tightly coupled to a preferred system as a single physical device. 

Detailed Description Text (291) : 

Using such DSP resources (and other hardware/software resources) , an analog voice signal is 
received or generated by the system (such as by a person speaking into a telephone, which 
creates an analog voice signal as they speak) . The analog voice preferably is converted to a 
Pulse Code Modulation (PCM) digital stream. (As is known in the art, PCM is a sampling 
technique for digitizing analog signals, especially audio signals. PCM samples the signal 8000 
times a second, and each sample is represented by 8 bits for a total of 64 Kbps. There are two 
standards for coding the sample level; the Mu-Law standard generally is used in North America 
and Japan, while the A-Law standard is used in most other countries.) Preferably, 
hardware/software of the system analyzes the PCM stream, and preferably echo is removed, voice 
activity detection (VAD) is performed, and tone detection is performed; remaining PCM samples 
are provided to the codec for processing. The voice codec (which may largely be implemented in 
software running on a processor) generally is used as part of the process of converting the 
originally analog signal to digital data packets suitable for transmission over a data network. 
In accordance with preferred embodiments of the present invention, different software codecs 
may be used in the process to convert analog signals to digital data in frames (also providing 
various levels of data compression; e.g., a G.729a frame may be 10 ms long and contain 10 bytes 
of speech), and then convert digital data back to analog signals. The goal when selecting a 
codec is to maintain high voice quality and low latency. Generally speaking, lower bit rate 
codecs offer higher complexity and, therefore, introduce higher latency. As a result, tradeoffs 
are made between the goals of low bit rate, high quality, low complexity and low latency. The 
actual choice will depend on the particular application and quality and bandwidth concerns. The 
various codec standards (i.e., the G. standards discussed earlier, publicly available standards 
data for which is hereby incorporated by reference, as with the other standards-related 
information for standards referenced herein) , generally may be evaluated and selected on the 
basis of criteria such as bit rate, quality, complexity, bandwidth usage or frame size and 
latency. In preferred embodiments, a G. 723.1 codec often is utilized. Packet assembler software 
preferably running on one of the DSP (within the provided DSP resources) receives frames from 
the codec and creates packets. Several frames may be combined in a single packet. In preferred 
embodiments, a 12 byte RTP header is added to each packet, which provides a sequence number and 
time stamp, and the packet thereafter is forwarded, preferably to a host or other processor for 
further processing. 

Detailed Description Text (292) : 

Addressing in VoIP is provided in a manner to determine from the dialed digits, preferably 
identified in the DSP, the destination IP address (e.g., 301-236-1895 . fwdarw. 193 . 148 . 100 . 2 ) . 
Such as from a lookup table under control of a processor (as part of the software/hardware 
resources of the system), a preferably 20 byte IP header is added to the packet, which contains 
(1) the IP address of the source system/gateway, and (2) the IP address of the destination 
system/gateway. An 8 byte UDP header containing source and destination sockets also is added. 
Systems (such as described herein or otherwise) on the network may then examine the IP address 
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to identify the route to the destination. It should be noted that several systems as described 
in the preferred embodiments herein may be in the path that the packets take to their 
destination . 



Detailed Description Text (293) : 

Among the problems encountered in VoIP communications are delay and echo. Delay causes problems 
such as echo and talker overlap. This problem is illustrated in FIG. 44. Echo typically is 
caused by signal reflections of the speaker's voice at the far end telephone equipment back 
into the speaker's ear. This echo is caused by a device called a hybrid, which typically is a 4 
wire to 2 wire converter. The telephone handset has 2 wires going to the ear piece and 2 wires 
going to the mouth piece, and inside the telephone those 4 wires need to be converted to only 2 
wires, which is what the telephone network typically uses (i.e., tip and ring). Echo generally 
becomes a significant problem when the round trip delay becomes greater than 50 milliseconds. 
Since echo is perceived as a significant quality problem, voice over data systems desirably 
will address the need for echo control and implement echo cancellation. Talker overlap, or the 
problem of one talker "stepping" on the other talker's speech, becomes significant if the one- 
way delay becomes greater than 250 ms . The end-to-end delay budget is therefore a significant 
consideration, and delay must be reduced through a packet network, which the present invention 
attempts to achieve. 

Detailed Description Text (297) : 

As an example, if a particular system/gateway negotiates a Rx packet time of 10 mSec with a 
remote system/gateway, in preferred embodiments the jitter buffer is automatically set to be in 
effect 30 mSec. Thus, without requiring an administrator to optimally set the jitter buffer 
size on a call-by-call basis, and without setting the jitter buffer size (or range) to be 
undesirably large to accommodate the largest possible desired size, in preferred embodiments 
the jitter buffer size/range is set automatically upon negotiation of the codec parameters, 
etc. Thus, codecs may be changed (such as automatically and on a preferably call-by-call or 
destination by destination basis), and a more optimal jitter buffer is automatically 
determined. More generally, as a VoIP call is set up (again, preferably on a call-by-call 
basis), which includes multiple protocols such as H.323 or MGCP, the particular codecs and 
codec parameters (which may be set by preferences on a destination by destination basis), a 
more optimal jitter buffer setting is automatically determined without further administrator 
intervention. Thus, protocol and code preferences may be determined such as by particular 
location/destination, and as calls are initiated by ordinary users, VoIP parameters are 
automatically retrieved (such as prioritized codec settings) and determined (such an 
automatically sized jitter buffer) . 

Detailed Description Text (299) : 

In addition, as congestion in the network may cause some packets to be dropped, left untreated 
the listener hears undesirable pops and clicks, etc. This is because IP networks do not 
guarantee service, lost packets can frequently occur. Under peak loads and congestion in the 
network, voice frames may be dropped equally with data frames (data frames, however, are not 
time sensitive and dropped packets may be corrected through the process of retransmission, 
etc.). In accordance with the present invention, to compensate for lost packets the system 
preferably replays the last packet received during the interval when the lost packet was 
supposed to be played out, which in a relatively simple manner fills the time between non- 
contiguous speech frames. Desirably, the DSP in preferred embodiments plays the last 
successfully received packet at a decreased volume (e.g., around a 3 dB reduction, or 1/2 
volume) in order to fill the gap. For multiple lost packets, the previously received packet may 
be replayed over and over at a more decreased volume to silence, which has been determined to 
be much more desirable than a sudden drop. Out of order packets also may result, given that the 
packets may take diverse routes through a network and may arrive out of order. In accordance 
with the present invention, out of order packets are not played in the order that they are 
received; if an out of order packet condition is detected, the missing packet is replaced, 
preferably, but its predecessor as if it is lost. When the late packet finally arrives, it 
generally is discarded. With such replacement algorithms for lost/out of sequence packets, and 
with automatic sizing of the jitter buffer, more optimum VoIP communications may be produced. 

Detailed Description Text (307) : 

One way to deal with this problem is to have one set of routing settings for all IP Telephony 
calls no matter where the call is going or coming from. This option is very limiting and 
undesirable. The other option is to define a way to specify source and destination information 
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for IP telephony calls. After defining source and destination, routing parameters may be 
associated with those defined sources and destinations. In other words, logical addressing of 
IP telephony calls will define the source and destination of the call and not the physical 
trunk that carries the voice data. This logical addressing is obviously the IP address or 
anything that resolve into the IP address of the source or destination of the IP telephony 
call. 



Detailed Description Text (308) : 

An IP Call Destination contains the IP address or a range of IP addresses of the end point 1 s IP 
telephony gateway. It also contains all the IP telephony call specific settings that the IP 
telephony manager software needs to use in order to make a successful call to that destination 
gateway, for example, codec preference order. This destination can be used instead of an 
outbound Voice Trunk Group anywhere a Trunk Group is used in the outbound routing algorithm 
settings. Specifically, in First Digit Table an IP Call Destination can be selected instead of 
a Trunk Group for the call to be routed to. Also IP Call Destination can be selected instead of 
an outbound Voice Trunk Group in outbound routing table steps. 

Detailed Description Text (309) : 

An IP Telephony Source contains the IP address or a range of IP addresses of the source gateway 
(where the call is coming from) . It also contains the settings that inbound routing algorithm 
needs to know to successfully route the call. These settings are similar to information that is 
stored in an inbound Voice Trunk Group for a traditional call. To make it easier for the 
administrator of the system to reuse these settings, the IP telephony Source configuration 
section preferably is divided into IP Source settings and Source IP Address sections. This way 
the administrator can have reusable set of settings that can be associated with several source 
IP addresses. Preferably, in accordance with the present invention this is similar to what 
Trunk Groups do for trunks. One of the main parameters in these settings is the Inbound Routing 
Table which is exactly the same as defined for traditional telephony. 

Detailed Description Text (312) : 

Inbound call routing for IP Telephony calls preferably uses the IP address of the source 
gateway to determine which IP Source Settings to use. This is very similar to a traditional 
call in which case the trunk that the call is coming from determines which inbound Voice Trunk 
Group to be used for inbound call routing. After this step everything is the same for IP 
Telephony inbound call routing and the traditional inbound call routing. 

Detailed Description Text (314) : 

A database table preferably is provided for the IP Call Destination. Each record in this table 
preferably defines a destination. Each IP Call Destination preferably has an ordered list of 
codec preferences, and preferably includes fields such as destination ID and/name, destination 
IP address, caller ID format, protocol (e.g., H.323 or MGCP), jitter buffer size parameters 
(see also the discussion elsewhere herein regarding jitter buffer sizing), send/receive volume 
settings, echo cancellation settings (e.g., filter size), silence suppression settings, voice 
activity detection settings (e.g., threshold) and the like. 

Detailed Description Text (315) : 

As it was mentioned before, there are two main paths that are preferably used to configure an 
outbound call to go over IP telephony. These two paths are: through an outbound routing table 
step or through First Digit Table. The preferably graphical interface for outbound Routing 
Table configuration preferably will merge the list of available IP destinations with the list 
of outbound Trunk Groups and present the combination to an administrator when they are 
selecting the destination for a routing table step. IP destinations, if chosen, will be used by 
the routing algorithm to route the call over the IP telephony. This is an important aspect of 
the present invention. The routing table may treat the VoIP telephony route as a step in the 
routing table. Thus, and as previously described, an assessment may be made of whether suitable 
conditions exist for a VoIP type call to be made, which may be made by attempting to establish 
a VoIP connection via a first step in a routing table. If the VoIP fails to complete, the 
system may automatically go to a next step in the routing table, which could be another VoIP 
step but more typically would be a type of traditional telephony Trunk Group/destination. Thus, 
in a desirable and automated manner, a VoIP call may be attempted, with a first step in the 
routing table, and with a traditional telephony call attempted (i.e., go the next step in the 
routing table) in the event of failure of the VoIP call, etc. This is illustrated in FIG. 46C, 
which shows a partial routing table with an initial IP telephony step, followed by voice 
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digital and voice analog Trunk Group steps, etc. The First Digit Table user interface 
preferably will merge the list of available outbound Trunk Groups with the list of available IP 
destinations and present it to user as the list of destinations. IP destinations, if chosen, 
will be used by the routing algorithm to route the call over the IP telephony. 

Detailed Description Text (316) : 

IP telephony inbound calls will be tagged by the IP address of the source of the call. Other 
than this, they preferably have all the characteristics of a non-IP call. Inbound routing 
algorithm determines if the call is an IP call based on the IP tag in which case it tries to 
match the source IP with one of the IP address patterns stored in a Source IP Address table. 
Based on this match it can determine the IP Source Settings record associated with this IP 
address . From this point on, an IP Source Settings record can be used like an inbound Trunk 
Group and inbound routing algorithm continues to route the call same way as a non-IP call. 
There are two tables preferably associated with inbound IP Telephony call configuration. Source 
IP Address table and IP Source Settings table. The Source IP Address Table preferably stores 
all the settings associated with a source IP address . The IP Source Settings Table preferably 
stores all of the information that inbound routing algorithm needs to know in order to be able 
to route the call correctly. 

Detailed Description Text (319) : 

FIG. 47A illustrates two communication systems 50 in geographically remote locations, such as 
in San Francisco and New York. In a first scenario (indicted by the solid line), a call may be 
made from an extension of the San Francisco communication system 50 to an extension of the New 
York communication system 50. Note that the numbers dialed may be a simple extension as is to a 
local extension. Based on the call routing and IP telephony parameter selections as described 
earlier, an IP telephony call may be established with the New York extension, which may be 
completed with the user simply dialing a simple (e.g., four digit) extension number. In a 
second scenario (indicated by the dotted line), a call may be made from an extension of the San 
Francisco communication system 50 to and an external telephone reached via a PSTN through the 
New York communication system 50. As illustrated, the user may dial a number for a phone in New 
York, and the San Francisco communication system 50 routes the call as an IP telephony call to 
the New York communication system 50, which then completes the call over the PSTN. This call 
may offer cost advantages in that it avoids the long distance toll charges in going from San 
Francisco to New York. In a third scenario (indicated by the dashed line), a call is made from 
an external telephone coupled to the San Francisco communication system 50 via the PSTN to an 
extension of the New York communication system 50. Note that the user of the external extension 
dials a local number for the San Francisco communication system 50, which may then route the 
call as an IP telephony call to the New York communication system 50. 

Detailed Description Text (321) : 

Referring now to FIG. 47B, an additional scenario in accordance with preferred embodiments of 
the present invention will now be described. In this exemplary scenario, an H.323 gatekeeper is 
coupled to the IP network. As an initial step of the scenario, a user enters an extension on a 
telephone coupled to the San Francisco communication system 50, which knows that the 
destination for this extension is an extension of the New York communication system 50. Based 
on the routing table information, etc., the San Francisco communication system 50 may then 
request a telephone number to IP address resolution from the H.323 gatekeeper coupled to the IP 
network. The call may then be routed by the San Francisco communication system 50 to the New 
York communication system 50 based on the IP address received from the H.323 gatekeeper. In 
such a scenario, various desirable aspects of preferred embodiments such as routing table 
selection, codec and codec parameter selection, jitter buffer sizing and the like (as described 
earlier herein) may be utilized in order to provide more optimal and cost effective IP 
telephony solutions. r 

Detailed Description Text (327) : 

In alternate embodiments, a mechanism is provided to prevent undesirable affects that could 
result if both sites attempt to switch over at the same time. In one such embodiment, assuming 
that both locations are equally capable of detecting network problems, the switchover is always 
initiated by the side with the "smaller" IP address . In other embodiments, as the IP call is 
set up, it is determined in advance which system shall be responsible for detecting IP network 
problems and initiating the switch over. 

Detailed Description Text (331) : 
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As, illustrated in FIG. 49C, however, in alternative embodiments an address of a particular card 
is read, where the card has been designed to have one address that simply allows the data bus 
pull up/pull down information to flow through to the requesting unit. For example, a processor 
on motherboard 624 could attempt to read a particular address of exemplary resource switch card 
623. The particular address of resource switch card 623, however, is designed so that the 
various elements of resource switch card 623 that may couple to either of buses 626 or 620 do 
not respond, while bus interfaces 628 allow the backplane encoded pull up/pull down information 
to pass from data bus 620 through resource switch card 623 to bus 626 (which may be a standard 
PC-type bus, such as an ISA bus) and motherboard 624. Thus, motherboard 624, which may be 
accessed remotely (as described elsewhere herein), may "poll" the hardware and determine the 
backplane encoded information by reading the particular address (the use of such a particular 
address is illustrated in FIG. 49D, which illustrates a bus read address of the location of the 
memory map allocated to resource switch card 623) . 

Detailed Description Text (337) : 

An exemplary process flow for use of such a deployment disk is as follows. The system may be 
shutdown, and the system restarted with the deployment disk inserted into the CD ROM drive 
while the system is booting up (in certain embodiments, certain cards may be removed from the 
system that are not necessary for software deployment) . Upon bootup, the system preferably 
provides a beep or series of beeps that provides an audible indication that the deployment disk 
is in. the CD ROM drive and has been recognized by the system. Preferably, one or more cards in 
the system, such as a resource switch card, will provide visual feedback, such as by blinking 
LEDs, which indicate that the system is ready to proceed. Preferably, a physical button must be 
depressed for a sufficient, predetermined length of time, which serves to ensure that the 
installer intends to deploy the software. Preferably a change in the audible output occurs so 
that feedback is provided, which may be accompanied by other visual feedback, that the 
deployment process has properly commenced. Initially, the program preferably verifies the 
system BIOS, and the model key, and upgrades them if necessary (this may be accompanied by a 
check of backplane encoding information as well) . Thereafter, files from the CD ROM preferably 
are copied onto a hard disk of the system. If successfully deployed, an audible tone is emitted 
to indicate successful deployment, which is preferably accompanied by visual feedback as well. 
Still preferably, the CD ROM is automatically ejected at the end of the process (typically the 
system must be rebooted in order to operate in accordance with the newly deployed software) . 

Detailed Description Paragraph Table (1) : 

TABLE 1 Label Where Description InCalls TUI Number of incoming calls answered (all types) 
MsgCreate MSS Number of messages created MsgSent IMDA Number of messages sent successfully 
MsgSendFail IMFSA Number of message send failures caused by an error in the Msg Subsystem 
MsgDelete MSS Number of message deleted MbxLogon MSS Number of times users logged on success- 
fully MbxLogoff MSS Number of times users logged off their mailbox (versus abandoned) 
TooManyErrors TUI Number of times callers were dropped because they made too many errors 
TooShort TUI Number of times messages recorded were too short Restart TUI Number of times the 
AA/VMS application was restarted/reloaded MWIOn MSS Number of requests to turn MWI On MWIOff 
MSS Number of requests to turn MWI Off MWIFail MSS Number of MWI (On/Off) requests that failed 
TMOOper TUI Number of calls transferred to Operator because of TMO ZeroOper TUI Number of calls 
transferred to Operator because caller dialed "0" ErrorOper TUI Number of calls transferred to 
Operator because of too many errors ErrorPassword TUI Number of calls dropped because of to 
many password errors. DiskFull MSS Number of times disk was too full to take a message 
ExtDirlnCall TUI Number of direct external (trunk) calls into AA/VMS ExtFwdlnCall TUI Number of 
external calls forwarding into AA/VMS IntDirlnCall TUI Number of direct internal (station) 
calls into AA/VMS IntFwdlnCall TUI Number of internal calls forwarding into AA/VMS NewMsg TUI 
Number of "new" messages recorded and sent by logged on users FwdMsg TUI Number of "forwarded" 
messages recorded and sent by logged on users ReplyMsg TUI Number of "reply" messages recorded 
and sent by logged on users MultAddress TUI Number of messages sent that had more than one 
address NameRecord TUI Number of times a Name message was recorded GreetRecord TUI Number of 
times a Greeting message was recorded 
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DOCUMENT-IDENTIFIER: US 6718177 Bl 

TITLE: System for communicating messages via a forward overhead control channel for a 
programmable logic control device 

Brief Summary Text (8): 

In view of the foregoing, there is a need for adapting the paging mechanism of a CMR system to 
support the transfer of commands and/or data for communications from an MSC to a cellular- 
compatible device. There is a further need for communicating with and controlling the 
operations of a remote controller, such as a PLC, coupled to a cellular-compatible device that 
can accept commands and/or data via the paging mechanism of a CMR system. 

Brief Summary Text (12) : 

In response to receiving at least one data page having a predetermined characteristic during 
the second time period, the cellular communications device can collect the data carried by the 
received data page. This data can be stored at the cellular communications device for 
subsequent use or is forwarded for processing by another device, such as a programmable logic 
controller (PLC) . To acknowledge receipt of the data, the cellular communications device can 
send an acknowledgement signal via the cellular network control channel. This acknowledgement 
signal can be formatted as a cellular telephony Autonomous Registration signal and carries an 
indication of data verification. A mobile switching center (MSC) typically receives the 
acknowledgement signal via the Reverse Overhead Control Channel (RECC) of the cellular network 
control channel . 

Detailed Description Text (10) : 

It is known that when a cellular mobile radiotelephone originates a call, it transmits a series 
of data messages to the serving cell. These messages, commonly referred to as Call Origination, 
are defined by EIA/TIA-553. These data messages contain the low order seven digi-ts of the • 
unit's telephone number, known as the Mobile Identification Number (MIN) , the unit's Station 
Class Mark (SCM) , which identifies functional characteristics of the unit, and the Called 
Address, or dialed telephone number . Cellular system operators typically also require 
additional data words to be transmitted that contain the MIN2, which is the high order three 
digits or NPA of the cellular unit f s telephone number, and the Electronic Serial Number (ESN). 
The MIN is assigned to a particular radiotelephone unit by the cellular service provider 
selected by the subscriber. The MIN typically contains information unique to the CMR system 
operator, for example, the first three digits of the MIN ("XXX") typically correspond to an 
area code, the next three digits ("XXX") typically correspond to a geographic location within 
the area code; and the final four digits ("XXXX") identify a particular piece of equipment. 
Similarly, the ESN is unique to each mobile cellular radiotelephone unit, and comprises a 
format that allows differentiation as to manufacturer and, in some cases, the model number, 
date of manufacture, and the like. 

Detailed Description Text (11) : 

These messages are provided first to the cell, and then through a data link to a mobile 
telephone switching center, otherwise described as a mobile switching center. The MSC, also 
known as a MTSO or a "switch, " makes voice connections between mobile radiotelephones and other 
telecommunications networks. At the MSC, a determination is typically made whether the 
radiotelephone is an authorized user or subscriber by looking up the unit f s telephone number, 
serial number, and other information supplied by the radiotelephone to see if there is an entry 
in the MSC's database corresponding to that particular telephone. An optional function of an 
MSC is to validate that the ESN and MIN received as part of a Call Origination message are 
valid. If the MIN is valid and the radiotelephone is identified as a subscriber within the 
given cellular system, i.e., a "home" unit, the received ESN is compared to the MSC ! s database 
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ESN entry to detect fraud. If these checks succeed, the cellular call is then allowed to 
proceed. 

Detailed Description Text (12) : 

It is also well known that when a mobile radiotelephone first powers up or first enters a CMR 
system when already powered, the unit can identify itself as actively present within the 
system. The radiotelephone identifies itself or "registers" through a process known as 
Autonomous Registration by supplying a data packet similar to that of a Call Origination 
message. The Autonomous Registration signal, also referred to as a registration or 
identification signal, typically comprises data fields for at least a mobile telephone number, 
i.e., the MIN, and an ESN. The original design attempt of Autonomous Registration was to 
improve the efficiency of potential future call deliveries by keeping the MSC informed of the 
approximate whereabouts of each individual radiotelephone unit, and to reduce paging channel 
load by lessening the need to page all cells to find a particular cellular unit. When the MSC 
is thus informed, it can later "page" or attempt to ring the cellular unit only in the cell or 
area that it was last known to be in. Additional cells would be paged only if the initial page 
did not locate the particular radiotelephone. Thus, Autonomous Registration is simply a set of 
messages periodically and autonomously sent from the mobile radiotelephone to the serving cell 
at an interval specified in data parameters previously received from the cell by the cellular 
unit . 

Detailed Description Text (17): 

The data message system 10 includes a set of data reporting devices 2 9, each comprising at 
least one controller 32 1 and a cellular communications device 34. A cellular communications 
device 34 can communicate with the MSC 24 via a control channel of the CMR system. The 
controller .32 1 , which is connected to one or more instruments or controllable items via a 
signal path 31', is typically implemented as a PLC for controlling the operations of a field 
instrument or a controllable item. The cellular communications device 34, which is connected to 
the controller 32' via a signal path 33', can communicate with the MSC 24 via a cellular 
network control channel 38 and accept page messages containing commands and/or data for use by 
the controller 32'. In addition, the cellular communications device 34 can transmit data 
messages, typically formatted as a Call Origination message or an Autonomous Registration 
signal, to the MSC 24 via the cellular network control channel 38. 

Detailed Description Text (36) : 

By using the data message format associated with an Autonomous Registration signal, the 
cellular communications device 34 "registers" with the MSC 24 by sending a data message that 
appears to contain a mobile telephone number and an ESN. Although it is not intended for the 
cellular communications device 34 to place a conventional voiced-based cellular telephone call, 
the cellular communications device 34 nevertheless registers for operation with the MSC 24, 
thereby enabling the communication of the selected data from the field. 

Detailed Description Text (37) : 

Alternatively, the format for the data message can be identical to the format or data record 
for a Call Origination signal that is transmitted by a cellular radiotelephone when it 
originates a telephone call. Similar to the format for a registration signal, the cellular 
communications device 34 can appear to originate a call by sending a data message formatted as 
a Call Origination signal to the MSC 24. Although the MSC 24 processes the data message as if 
it contained a mobile telephone number and an ESN, the data message is actually used to 
communicate selected data placed within one or more data fills normally reserved for the mobile 
telephone number and the ESN. Although the Call Origination signal format can be used to 
transport data from the cellular communications device to the MSC, it will be understood that 
the data message system 10 is employing this format for data communication rather than for call 
origination . 

Detailed Description Text (38) : 

As shown in the data record 50 in FIG. 2, the standard message format for a registration signal 
(call origination) has been adapted by the data message to permit the identification of the 
particular transmitting cellular communications device 34 and the communication of the selected 
data. In particular, the data field 52 for the predetermined identifying characteristic 
corresponds to at least a portion of a mobile telephone number or MIN assigned to the cellular 
communications device 34. Thus, the predetermined identifying characteristic is substituted 
within the data field normally reserved for the MIN in an identification signal. This 
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predetermined identifying characteristic can belong to a set of unassigned mobile telephone 
numbers . Alternatively, the predetermined identifying characteristic assigned to each cellular 
communications device 34 can be a conventional telephone number or a set of 10 digits. The 
predetermined identifying characteristic permits the identification of the source of the data 
by uniquely identifying the cellular communications device 34. The predetermined identifying 
characteristic also supplies information used by the MSC 24 to recognize that the data message 
containing this predetermined identifying characteristic is associated with the data collection 
system 40. 

Detailed Description Text (54) : 

The receiver 78 can receive pages from the MSC 24 via the FOCC of the control channel 38. For 
example, the MSC 24 can output command signals, which are formatted as pages, via the control 
channel 38 to initiate certain operations or to control certain functions of one or more of the 
cellular communications devices 34 within the cell 12. The receiver 78 can monitor the control 
channel 38 for finite time periods defined by a clock signal output by the clock 82. For 
example, the clock 82 can operate as a timer defining a time period for a monitoring operation 
completed by the receiver 78. The cellular communications device 34 can respond to a command 
signal by conducting a particular operation or by controlling a certain function associated 
with the command signal. 

Detailed Description Text (56) : 

The command signal is preferably a 10 digit number that represents a conventional mobile 
telephone number . At least a portion of this telephone number can be assigned as an identifier 
for a corresponding cellular communications device 34. The remaining portion (if any) of the 
10-digit telephone number can represent a command or data for a particular operation or 
function. In this manner, a cellular communications device 34 can be programmed to respond only 
to a command signal containing its address data and to conduct the particular operation or 
function identified by the command. 

Detailed Description Text (59) : 

The opportunity for placing a command or data, or a combination of a command and data, within 
the conventional format of a paging message is limited by the defined character length of the 
paging message, typically the 10-digit telephone number or MIN. For relatively short data 
lengths, the transmission of a single independent page message from an MSC to a cellular device 
in the manner known to the art is useful to support limited communications. This fixed data 
length for a page message is satisfactory for the paging communication task of conventional CMR 
system operations, namely, the polling of one or more mobile radiotelephones within the 
coverage area of the CMR system. This polling technique only requires the transmission of a 
single discrete page message to prompt a response from a mobile radiotelephone unit that 
receives the page. Prior to the present invention, there was no readily available mechanism for 
exploiting the paging message mechanism to transfer an expanded data set. 

Detailed Description Text (103) : 

If a programming change occurs locally, typically by the end user or a field technician, in a 
schedule look-up table, then the target radio can issue a registration sequence to the MSC. In 
turn, the MSC can forward this information to the data collection system as an update for the 
schedule information maintained at an Operations Center responsible for schedules. 

Detailed Description Text (107): 

In decision step 735, a determination is made whether the cellular communications device has 
received additional scheduled command pages containing data during a predetermined time period. 
If the response to this inquiry is negative, the "NO" branch is followed from step 735 to step 
710 to continue monitoring operations at the cellular communications device. If, on the other 
hand, the cellular communications device has received additional schedule command pages in a 
timely fashion, the "YES" branch is followed to step 740. For an exemplary embodiment, 
programming data is typically carried by this pair of additional scheduled command pages. The 
programming data carried by the additional scheduled command pages is extracted by the cellular 
communications device and forwarded to the PLC in step 740. This programming data can be 
combined with the slot number and programming data received by the PLC in step 725 to support a 
reprogramming operation at the PLC. For example, the combination of programming data can be 
stored by a look-up table at the slot number identified by a received scheduled command page to 
update or to reprogram the programming data at that look-up table slot. 
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DOCUMENT-IDENTIFIER: US 6891940 Bl 

TITLE: System and method for providing remote access to telecommunications services 
Abstract Text (1) : 

A system and method are provided for reviewing and updating a subscriber 1 s telecommunications 
services, including a Caller ID service, using a graphical user interface via multiple data 
networks. The method includes presenting service data to the subscriber via the data networks 
and transmitting a data message from the subscriber to an intelligent peripheral via at least 
one of the data networks. The data message indicates a subscriber's desired update to a 
selected telecommunications service. The method also includes converting the data message into 
a protocol compatible with an integrated service control point. The converted data message is 
identical to a data message that the intelligent peripheral would create if the subscriber had 
entered the desired update via an interactive voice response system. The method further 
includes transmitting the converted data message to the integrated service control point, and 
updating the selected telecommunications service in accordance with the subscriber's desired 
update . Thus, the selected telecommunications service is updated substantially 
contemporaneously with the subscriber requesting the update at the graphical user interface. 
Moreover, the subscriber retains the ability to update and review service data via an 
interactive voice response. The method and system also enable the subscriber to view Caller ID 
information while being located remotely from the destination of the telephone call associated 
with the caller ID information. 



Brief Summary Text (3) : 

The present invention relates to the field of telecommunications. More particularly, the 
present invention relates to a Personal Call Manager, a.k.a. Personal Communications Manager 
(PCM) providing subscribers integrated access to communications services through a data 
network, such services include a Remote Access to Caller Identification (RACLID) system. The 
RACLID system enables subscribers to review caller identification information associated with 
incoming calls to the subscriber 1 s telephone line from a remote location. 

Brief Summary Text (5) : 

The written description provided herein contains acronyms which refer to various 
telecommunications services, components and techniques, as well as features relating to the 
present invention. Although some of these acronyms are known, use of these acronyms is not 
strictly standardized in the art. For purposes of the written description herein, the acronyms 
are defined as follows: Advanced Intelligent Network (AIN) Authentication/Subscription 
Information (ASI) Caller Identification (Caller ID) Customer Premises Equipment (CPE) Dual Tone 
Multi-Frequency (DTMF) Graphical User Interface (GUI) Generic Data Interface (GDI ) HyperText 
Mark-Up Language (HTML) HyperText Transfer Language Protocol (HTTP) Incoming Call Manager (ICM) 
Integrated Service Control Point (ISCP) Interactive Voice Response (IVR) Java Database 
Conductivity (JDBC) Lightweight Directory Access Protocol (LDAP) Line Information Database 

(LIDB) Outgoing Call Control (OCC) Personal Computer (PC) Personal Call Manager/Personal 
Communications Manager (PCM) Personal Identification Number (PIN) Public Switched Telephone 
Network (PSTN) Remote Access to Caller Identification (RACLID) Service Management System (SMS) 
Service Node (SN) Service Switching Point (SSP) Signaling System 7 (SS7) Signaling Transfer 
Point (STP) Terminating Attempt Trigger (TAT) Transaction Capabilities Application Part (TCAP) 
Transmission Control Protocol/internet Protocol (TCP/IP) User Interface (UI) World Wide Web 

(WWW) 

Brief Summary Text (7) : 

Currently, subscribers to call control services within the Public Switched Telephone Network 
(PSTN) are able to initiate and modify their services by calling a customer service 
representative or by interacting with an Interactive Voice Response (IVR) system using a 
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standard Dual Tone Multi-Frequency (DTMF) telephone device. These methods practically limit the 
number and types of services that can be provided to and modified by the subscribers because 
all information pertaining to the services is presented audibly. In addition, the potential 
market for subscribers to call control services is not fully exploited because of customer 
reluctance to use IVR systems. An additional drawback is that, conventionally, each PSTN 
service has a corresponding IVR interface, so that as a customer subscribes to additional 
services, he or she must keep track of additional IVR telephone numbers and Personal 
Identification Numbers (PINs) . 



Brief Summary Text (8) : 

There have been attempts to remedy the problems associated with IVR access to PSTN services. 
These attempts incorporate use of packet switched data networks, such as the Internet, to avoid 
conventional IVR systems and to streamline the initiation and modification functions. The 
current Internet based systems have several drawbacks, however, including the inability to 
ensure near real-time update of services and incompatibility with existing IVR implementations. 



Brief Summary Text (9) : 

For many call control services, the subscribers must submit requests to the customer service 
arm of their provider to initiate new services or update existing ones. The requests are 
implemented according to the provider's time line and discretion. It is difficult for the users 
to gauge when the service alteration will take effect. Also, because the current Internet based 
systems operate exclusively from the conventional IVR systems, i.e., the two systems cannot 
coexist, customers must select either the Internet interface or the IVR interface. 
Consequently, a customer who has selected the Internet interface, and who is without a PC 
and/or Internet access, is not able to make desired changes to his or her services through an 
IVR. The inability to implement desired changes is especially troublesome considering that 
users are often interested in altering some call services (e.g., call forwarding, paging, and 
caller ID) when they are away from their home or business telephone and PC. 

Brief Summary Text (10) : 

An example of call control services provided over a packet switched data network is described 
in CHANG et al . , U.S. Pat. No. 5,958,016, which teaches enabling Advanced Intelligence Network 
(AIN) services over the World Wide Web (WWW) through a provisioning system called the Service 
Management System (SMS). The SMS as disclosed in CHANG et al . , however, does not ensure near 
real-time data update and is not compatible with existing IVR implementations. 

Brief Summary Text (11) : 

Therefore, the services presented via the Web are limited in functionality to the extent near 
real-time data updates are not guaranteed. For example, if a subscriber modifies an incoming 
call service, which blocks calls from selected phone numbers or classes of phone numbers, to 
add an allowed incoming phone number, the subscriber will not begin immediately to receive 
calls from the previously blocked phone number. Rather, the subscriber must wait an unspecified 
period of time for the service to be updated via the SMS. Also, as discussed above, the Web 
interface and the IVR interface are mutually exclusive. 

Brief Summary Text (12) : 

The present invention pertains to a Personal Call Manager, a.k.a. a Personal Communications 
Manager (PCM) system that resolves these problems, simply and efficiently. The PCM provides an 
interface to telecommunication services, such as personal directories, Incoming Call Manager 

(ICM), Outgoing Call Control (OCC) and the like. In addition, the PCM interfaces to an improved 
caller identification (Caller ID) system, referred to as Remote Access to Caller Identification 

(RACLID) . Conventional Caller ID services provided through the PSTN necessitate the attachment 
of Customer Premises Equipment (CPE) to a telephone jack corresponding to the telephone number 

(s) subscribing to the Caller ID service. The user may review a log of Caller ID information 
associated with incoming calls by physically reviewing the information displayed on the CPE. 
Typically, the Caller ID information includes the name and/or number of the calling party, as 
well as the date and time of the incoming telephone call. 

Brief Summary Text (13) : 

A limitation of the conventional service is that, in order to review the Caller ID information, 
the subscriber must be present at the CPE. It would be advantageous, however, for subscribers 
to be able to review their Caller ID information remotely, e.g., at work, while commuting, on 
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vacation, etc. Because callers do not always leave messages on an answering device or service, 
which may be remotely accessible, a subscriber cannot determine through the conventional Caller 
ID service who has attempted to call until the subscriber physically returns and views the CPE. 
Consequently, the conventional Caller ID system has several drawbacks, including delayed 
awareness of incoming telephone calls and subsequently delayed response to those calls. 

Brief Summary Text (15) : 

However, these attempts have several inherent disadvantages. For instance, in both DANNE et al . 
and VOIT et al . , processing of the telephone call is interrupted in order to perform the Caller 
ID function. Also, the methods provide Caller ID information only when the call is in progress, 
and in the case of DANNE et al . , only when the user is online and running a JAVA application. 
That is, the user cannot obtain the Caller ID information at his or her convenience. Finally, a 
significant portion of the intelligence aspects of the DANNE et al. Caller ID system is 
required to be in the terminals, thus limiting the types of devices that can access the Caller 
ID information. 

Detailed Description Text (3) : 

An aspect of the present invention provides a user / subscriber access to a PCM system through a 
communications network, including the Internet and other data networks, without excluding the 
possibility of conventional IVR access. Thus, the subscriber can conveniently customize 
services managed by the PCM through a graphical user interface (GUI) that efficiently presents 
the complex data associated with the managed services with minimal service provider 
interaction. Another aspect of the invention provides for updating the actual service data in 
the PSTN substantially contemporaneously with access to the service data via the PCM, 
permitting near real-time access to the services managed by the PCM. 

Detailed Description Text (4) : 

In another aspect of the present invention, the PCM manages multiple services, including, for 
example, Caller ID. Thus, the present invention provides the subscriber access to Caller ID 
information remotely over the communications network in an efficient and user-friendly manner. 

Detailed Description Text (5) : 

According to another aspect of the present invention, a method is provided for reviewing 
service data relating to a subscriber 1 s telecommunications services using a graphical user 
interface. The method includes transmitting a data message from the subscriber to an 
intelligent peripheral through at least one data network, the data message indicating a 
subscriber 1 s desire to review the service data, and converting the data message into a protocol 
compatible with an integrated service control point. The converted data message is identical to 
a data message that the intelligent peripheral would create if the subscriber had indicated the 
desire to review the service data via an interactive voice response system. The protocol may be 
the SR-3511 protocol. Then, the converted data message is transmitted to and the service data 
is retrieved from the integrated service control point. The service data is forwarded to the 
subscriber through the intelligent peripheral. The subscriber retains the ability to review 
service data through an interactive voice response. 

Detailed Description Text (6) : 

In another aspect of the present invention, a method is provided for reviewing and updating a 
subscriber 1 s telecommunications services using a graphical user interface through multiple data 
networks, including presenting service data to the subscriber through the data networks and 
transmitting a data message from the subscriber to an intelligent peripheral through at least 
one of the data networks. The data message indicates the subscriber's desired update to a 
selected telecommunications service. The data message is converted into a protocol compatible 
with an integrated service control point, which protocol includes the SR-3511 protocol. The 
converted data message is identical to a data message that the intelligent peripheral would 
create if the subscriber had entered the desired update through an interactive voice response 
system. Then, the converted data message is transmitted to the integrated service control point 
and the selected telecommunications service is updated in accordance with the subscriber 1 s 
desired update . The selected telecommunications service is updated substantially 
contemporaneously with the subscriber requesting the update at the graphical user interface. 
Also, the subscriber retains the ability to update and review service data through an 
interactive voice response. The presentation of service data may include retrieving the service 
data from a service status database, which is periodically updated by the integrated service 
control point. This reduces traffic through the integrated service control point. 
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Detailed Description Text (7) : 

In a further aspect of the present invention, a method is provided for accessing service data 
relating to a subscriber's telecommunications services using a graphical user interface (GUI) 
through multiple data networks, and using an interactive voice response (IVR) system through a 
public switched telecommunications network. The method includes providing the subscriber with 
the option of accessing the service data through more than one interface, including the IVR 
system and the GUI, and the subscriber selecting either the IVR system or the GUI. The service 
data is accessed through an intelligent peripheral, which obtains the service data from an 
integrated service control point. The service data is presented to the subscriber through the 
selected interface, so that the subscriber can access the service data through the IVR system 
or the GUI, based upon the subscriber 1 s selection. 

Detailed Description Text (8) : 

According to another aspect of the present invention, a system is provided for reviewing and 
updating a subscriber's telecommunications services using a graphical user interface through 
multiple data networks. The system includes a Web client, through which the subscriber views 
service data received through the data networks and requests service data updates . The service 
data is viewed through a graphical user interface. The system further includes a Web server 
that receives a data message, which indicates a subscriber's desired update to a selected 
telecommunications service, transmitted from the subscriber in response to a service data 
update and an intelligent peripheral, which receives the data message via at least one of the 
data networks. The intelligent peripheral translates the data message into a standard protocol, 
which includes the SR-3511 protocol. The translated data message is identical to a data message 
that the intelligent peripheral would create if the subscriber had entered the desired update 
through an interactive voice response system. The system also includes an integrated service 
control point that receives the message in the standard protocol and updates the selected 
telecommunications service in accordance with the subscriber's desired update . The selected 
telecommunications service is updated in the integrated service control point substantially 
contemporaneously with the subscriber requesting the update at the graphical user interface. 
Furthermore, the subscriber retains the ability to update and review the service data through 
an interactive voice response. The system may include a service status database from which the 
service data is initially retrieved, thereby reducing traffic on the integrated service control 
point. 

Detailed Description Text (9) : 

In another aspect of the present invention, a method is provided for accessing caller ID data 
relating to a subscriber ' s remote access to caller ID service using a graphical user interface 
(GUI). The method includes identifying selected telecommunications services managed by a 
personal call manager account belonging to the subscriber, at least one which is the remote 
access to caller ID service. The telecommunications services are presented to the subscriber at 
the GUI through at least one data network. The subscriber then queries an intelligent 
peripheral through the data network indicating the subscriber ' s desire to access the remote 
access to caller ID service. The caller data is then retrieved from a call logger database, 
which stores the caller ID data, in response to the query. The caller ID data is transmitted to 
the subscriber through the data network and is displayed at the GUI. 

Detailed Description Text (10) : 

In a still further aspect of the present invention, a method is provided for providing caller 
ID information associated with a telephone call from a calling party to a destination, the 
caller ID information being provided over multiple networks to a subscriber at a location 
remote from the destination. The method includes storing caller ID data in a call logger 
database in response to the calling party placing the telephone call to the destination. A 
caller ID query is received from the remotely located subscriber through at least one of the 
networks. In response to the caller ID query, the caller ID data is retrieved from the call 
logger database, transmitted to the remotely located subscriber through at least two of the 
networks and displayed at the remote subscriber ' s location. 

Detailed Description Text (11) : 

The method for providing caller ID information to a subscriber at a location remote from the 
telephone call destination may further include initially launching an AIN trigger when the 
calling party places the telephone call to the destination which subscribes to a remote caller 
ID service. In that case, the storing of caller ID data includes transmitting calling party 
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information associated with the calling party from an integrated service control point to a GDI 
server, obtaining additional information from a directory server based upon the calling party 
information and transmitting the caller ID information from the GDI server to the call logger 
database. The additional information can be obtained from the directory server by either the 
GDI server or by the integrated service control point, which forwards the additional 
information to the GDI server. The caller ID information may include the calling party 
information and the additional information. 

Detailed Description Text (12) : 

The method for providing caller ID information to a subscriber at a location remote from the 
telephone call destination may also include determining whether the subscriber has activated 
the remote caller ID service. Also, at least one of the networks may be a packet switched data 
network, which may include the Internet. Also, receiving the caller ID query may include 
receiving at a Web server the caller ID query from the subscriber through a Web client, so that 
transmitting the caller ID data to the remotely connected subscriber includes transmitting the 
caller ID data from the Web server to the web client. 

Detailed Description Text (13) : 

In another aspect of the present invention, a system is provided for providing caller ID 
information, associated with a telephone call from a calling party to a destination, to a 
subscriber at a location remote from the destination. The system includes an advanced 
intelligent network (AIN) , which includes an integrated service control point that forwards 
calling party information in response to the telephone call, and a private network, which 
includes multiple servers in communication with one another. A first group of servers forwards 
caller ID information based upon the received calling party information, to a call logger 
database. The system further includes a public network, including a client which sends a caller 
ID query to a second group of servers. The public network .retrieves the caller ID information 
from the call logger database and sends the caller ID information to the client. The subscriber 
can view the caller ID information while being located remotely from the destination of the 
telephone call associated with the caller ID information. The public network may be the 
Internet and the client may be a Web browser. 

Detailed Description Text (14) : 

According to another aspect of the present invention, a system is provided for providing caller 
ID information, associated with a telephone call from a calling party to a destination, to a 
subscriber at a location remote from the destination. The system includes a switch, associated 
with the destination, that receives the telephone call from the calling party. The switch has 
an AIN trigger set to launch a query in response to the telephone call. The system further 
includes an integrated service control point that forwards calling party information in 
response to the query and an interface server that obtains additional information from a 
directory server, based upon the received calling party information. The caller ID information 
includes the additional information and the calling party information. The system further 
includes a call logger database that receives the caller ID information from the interface 
server and stores the caller ID information. The system also includes a Web client that 
forwards a caller ID query from the subscriber and a Web server that receives the caller ID 
query from the Web client over the Internet and, in response to the query, retrieves the caller 
ID data from the call logger database and forwards the caller ID data to the Web client for 
display to the subscriber . The subscriber can view the caller ID information while being 
located remotely from the destination of the telephone call associated with the caller ID 
information. 

Detailed Description Text (15) : 

The present invention is an AIN based system and method that allows a PCM subscriber connected 
to a communications network, including the Internet and other packet switched type data 
networks, as well as through conventional IVR systems, to customize and execute services 
associated with telephonic communications, with near real-time access to the service data. FIG. 
1 illustrates an exemplary telecommunications network (e.g., PSTN) in association with the 
present invention. The network includes a calling party 20, an originating Service Switching 
Point (SSP) 21, a terminating SSP 24 and a subscriber's telephone (i.e., the destination) 25. 
The network also includes a Signaling Transfer Point (STP) 22, an Integrated System Control 
Point (ISCP) 23 and an Advanced Intelligence Network-Intelligent Peripheral (AIN-IP or 
intelligent peripheral) 40. The intelligent peripheral 40 includes an interactive voice 
response (IVR) system. By way of example, the ISCP 23 may be implemented with the Bellcore 
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Integrated Service Control Point, loaded with ISCP software Version 4.4 (or higher), available 
from Telecordia, Murray Hill, N.J. 

Detailed Description Text (17) : 

The user is able to access the intelligent peripheral 40 through the Web server 43, which is in 
communication with the Internet 44 or other packet switched data network. The user is 
alternatively able to access the intelligent peripheral 40 through the IVR system 45 using a 
conventional DTMF telephone connection. When using the Internet, the user accesses the Web 
server 43 with a PC, acting as a Web client 30, using software such as ICW Client, available 
from Southwestern Bell Telephone Company. The Web client may likewise incorporate a Web 
browser, such as Microsoft Internet Explorer, available from Microsoft Corporation, or Netscape 
Navigator. In one embodiment, the Web client 30 is implemented with an IBM Pentium based 
computer, running the -Linux or Microsoft Windows operating system and the Microsoft Internet 
Explorer, Netscape Navigator or Hotjava, available from Sun Microsystems, Inc., Web browser 
software. An embodiment of the invention with respect to the Web server 43 may include running 
the Linux or Microsoft Windows operating system and the Apache Web server software, available 
from the Apache Software Foundation, or the Jigsaw Web server software, available from World 
Wide Web Consortium (W3C) . 

Detailed Description Text (18) : 

The SSP 24 is the terminating central office (CO) for the PCM subscriber 25 and the SSP 21 is 
the originating CO for the calling party 20. However, the terminating CO and the originating CO 
may be the same. The SSPs 21 and 24 may comprise, for example, 1AESS or 5ESS switches 
manufactured by Lucent Technologies, Inc., or DMS-100 switches manufactured by Nortel Networks 
Corporation (Nortel), or AXE-10 switches manufactured by Telef onaktiebolaget LM Ericsson. 

Detailed Description Text (20) : 

FIG. 2 is an exemplary call flow diagram depicting a subscriber using the PCM service. 
Initially, the subscriber accesses a public packet switched data network, such as the Internet, 
from a Web client 30, using a Web browser such as Microsoft Internet Explorer, Netscape 
Navigator or Hot Java . Once on the Internet, the subscriber connects to. the Web server 43, which 
serves as a secure access platform. The Web server 43 receives HyperText Transfer Language 
Protocol (HTTP) messages from the Web client 30 and provides HyperText Mark-Up Language (HTML) 
Web pages in response to the subscriber 1 s input to the Web client 30. The Web pages relate to 
the subscriber 1 s PCM account. 

Detailed Description Text (21) : 

Once connected to the Web server 43, the user must first log-in to the PCM account, also 
depicted at block 301 in FIG. 3 and described below. The log-in equates to an authentication of 
the user. To perform the authentication, the Web server 43 contacts the 

Authentication/Subscription Information (ASI) Server 42, which confirms that the subscriber is 
an authorized user by verifying at least the subscriber's name and a password. The ASI Server 
42 also provides' to the Web server 43 a list of the services to which the user has subscribed 
in the PCM account. Services for each phone number are linked to the PCM account through the 
ASI Server 42. 

Detailed Description Text (23) : 

In another embodiment, depicted in FIG. 2A, the Web server 43 retrieves from a Service Status 
Database 41 the data and status of the various services managed through the PCM account, rather 
than from the ISCP 23, directly. This database serves as a cache for the service information in 
the ISCP 23. The Service Status Database 41 contains information current to the most recent 
update interface with the ISCP 23. The cache arrangement enables the user to efficiently access 
this information without waiting for the ISCP 23 to process the request. At the same time, it 
reduces ISCP traffic. The Service Status Database 41 is refreshed periodically to ensure 
currency, as well as pursuant to specific command by the user. This database is a conventional 
Lightweight Directory Access Protocol (LDAP) , such as the LDAP available from Lucent 
Technologies, Inc. In the alternative, the database may be a standard relational database, such 
as those available from Oracle Corporation or Sybase, Inc. 

Detailed Description Text (25) : 

At this point, the- user may choose to update or to simply review the service information. When 
the service is updated, the Web server 43 sends the update instructions in a data message to 
the intelligent peripheral 40. The intelligent peripheral then translates the update 
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instruction into the SR-3511 protocol and communicates the updated service parameters directly 
to the ISCP 23. 

Detailed Description Text (26) : 

For example, one available service is Incoming Call Manager (ICM) , by which the user may 
prioritize, forward, preview or block selected telephone numbers. In the update procedure, the 
user enters a telephone number to be blocked, for instance, which the Web server 43 
communicates to the intelligent peripheral 40. The intelligent peripheral, in turn, sends the 
data via SR-3511 to the ISCP 23, which flags the number to be blocked. Because the intelligent 
peripherals instructions to the ISCP 23 are sent and implemented immediately, without the 
involvement of the provider's account management or customer service, the changes to the 
service are operable and available shortly after the user sends the instructions. In an 
embodiment that includes the Service Status Database 41, the cache will then be updated in due 
course to reflect the updated information in the ISCP 23. 

Detailed Description Text (27) : 

FIG. 3 depicts the procedure followed by the' subscriber when first entering the PCM Web site. 
The subscriber must first log-in at block 301. Assuming the subscriber 1 s PCM account has 
already been established, as described below, he or she must provide the authentication data to 
proceed. The authentication data is entered at a log-in screen, an example of which is depicted 
in FIG. 4 at screen 401. To maintain the integrity of the secure platform, authentication 
requires preferably a user ID and a password. The user ID is any name, not necessarily unique 
within the PCM system, selected at account initiation by the subscriber . The password is 
confidential (at the subscriber 1 s discretion) and must be unique with respect to the associated 
user ID. The subscriber may change the password as desired, but appropriate authentication data 
must be provided prior to such changes. If the subscriber enters an invalid user ID or 
password, the Web server 43 responds with a message explaining the problem and allows another 
chance to enter correct data. 

Detailed Description Text (28) : 

After the subscriber is authenticated, the subscriber proceeds to enter the PCM at block 302. 
At this time, the user views a general informational screen 402, which is formatted at the 
discrettion of the service provider. It may include, by way of example, new services offered to 
the subscriber . After the subscriber elects to proceed into the PCM, the Web server 43 
navigates to a page 404 that displays telephone numbers associated with the PCM account (s) to 
which the user belongs and to which the user is authorized to access. FIG. 5 depicts an 
exemplary screen displaying phone numbers to which the user has access. At this point, the user 
selects a telephone number at block 303 and the corresponding services are displayed for the 
selected telephone number at screen 403. The user may then elect to implement the various 
services in place for a particular phone number or, depending on the user's privileges within a 
particular account, such as a superuser or a PCM user (described later) , to manage the PCM 
account. 

Detailed Description Text (29) : 

If the PCM has more than one associated telephone number, the user would see a Web page listing 
the numbers, as in block 404 of FIG. 4. The screen has user interface elements that allow the 
user to select one of the numbers. Thus, each PCM account keeps track of a nonempty set of 
phone numbers to be managed through the PCM on behalf of the corresponding set of users, 
presumably members of a family, business, organization or other group. 

Detailed Description Text (30) : 

After the user selects a phone number at block 303, the system displays for the user a PCM 
summary page 304 corresponding to the selected telephone number. The PCM summary page displays 
only data the user is authorized to see for the selected telephone number. As shown at screen 
403, the PCM summary provides various options to the user, including by way of example, 
selecting from among listed services 306-309, returning to select an alternative PCM telephone 
number or exiting PCM altogether 313. 

Detailed Description Text (31) : 

FIG. 6 shows an exemplary PCM summary display, which corresponds to screen 403 of FIG. 4, 
entitled Personal Call Manager Home Page for account number (512) 555-5831, which is the 
selected telephone number in the example. FIG. 6 shows four services accessible through the 
PCM, although the four services are not intended to be limiting. That is, the PCM is able to 
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administer any call services associated with an ISCP 23. The services depicted in the PCM 
summary screen 403, as well as in FIG. 6, are Caller ID Log 601, Message Center 602, Incoming 
Call Manager (ICM) 603 and Outgoing Call Control (OCC) 604. The displayed information is 
summary in fashion, the details being available to the user through selection of one of the 
available services, which displays a PCM Service screen 405. In the depicted embodiment, the 
summary as well as the detailed data is provided through the Web server 43 from the ISCP 23 or 
a Call Logger Database 95 (shown in FIG. 8 and discussed in detail below), depending on the 
service selected. At the summary screen, the Caller ID Log 601 retrieves data from the Call 
Logger Database 95 and shows, for example, the number of call records added since the last 
review and the Message Center 602 likewise retrieves data from the Call Logger Database 95 and 
shows the number of new call notes, e-mails, wireless calls, faxes and messages reviewed. The 
ICM 603 retrieves data from the ISCP 23 and shows the status of the call blocker, call 
forwarding, priority call and caller preview features and an Outgoing (OCC) summary retrieves 
data from the ISCP 23 and shows whether international calls, long distance calls, 900/976 
numbers and/or directory assistance calls are restricted. 

Detailed Description Text (33) : 

The paging capability provides the option of paging the subscriber when a Caller ID is received 
from a subscriber specified phone number. Paging may include a page, a wireless short message, 
an email, or a generated phone call to a specified number. Moreover, Caller ID logs can be 
collected and paged to the subscriber at periodic intervals with summary and/o.r detailed 
information. 

Detailed Description Text (35) : 

In one embodiment of the invention, a Remote Access Caller Identification (RACLID) service is 
offered as one of the services available to the user. The RACLID service permits subscribers to 
access their Caller ID data when they do not have access to customer premises equipment, such 
as their Caller ID box. Conventional implementation of Caller ID presupposes delivery over the 
subscriber's telephone line to a Caller ID box attached to that line. According to the 
invention, the Caller ID data is delivered via the data networks (including, for example, the 
Internet) to the subscriber . Where RACLID is available and incorporated into the PCM, it is 
specifically listed as one of the selectable services at the PCM Summary page 403. 

Detailed Description Text (36) : 

As in the case of the other services in PCM, the subscriber can review caller data using RACLID 
from any location with networking facilities that allows connection to the data network on 
which the Caller ID data is stored. The networking facilities would include the Internet, a 
corporate intranet or other TCP/IP network. Also, RACLID may be provided without PCM. 

Detailed Description Text (38) : 

Outside the PSTN network, the RACLID service requires multiple servers and databases, also 
depicted in FIG. 9. These elements include a GDI server 92, a directory server 93, a Web server 
43 and a Call Logger Database 95. Generally speaking, the GDI server 92 interfaces with the GDI 
client 91, facilitating communication between the PSTN and the RACLID networks. The directory 
server 93 contains information stored by the RACLID provider, including data associated with 
the accessible universe of telephone numbers, regardless of whether they are associated with 
RACLID subscribers . It also stores authentication data corresponding to RACLID subscribers . In 
an embodiment of the invention, the directory server 93 can be incorporated into the AIS server 
42, which contains authentication data corresponding to PCM in general. In another embodiment, 
the information stored at the directory server 93 may be incorporated into the Web server 43. 
The Web server 43 connects the subscriber through the Web client 30 via a data network 44, such 
as the, Internet, and conducts the various interactive operations with RACLID. In alternative 
embodiments, the Web client 30 is implemented with an IBM Pentium based computer running the 
Linux or Microsoft Windows operating system and a Web browser, such as Microsoft Internet 
Explorer or Netscape Navigator. The Call Logger Database 95 contains data associated with 
specific RACLID accounts. In an embodiment of the invention, the Call Logger Database can be 
incorporated into the Service Status Database 41. 

Detailed Description Text (39) : 

Referring to FIG. 9, the RACLID system is initiated by an AIN Terminating Attempt Trigger (TAT) 
launched by the SSP 24 whenever a call is placed by the call originator 20 to a RACLID 
subscriber 1 s phone 25. Once the trigger has been assigned and activated, every call terminating 
to the PCM subscriber 1 s line will cause the SSP 24 to launch a TAT query via the existing 
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Signaling System 7 (SS7) network (and appropriate STP 22) to the ISCP 23. The SSP 24 is the 
terminating central office for the RACLID subscriber . The TAT is assigned to the RACLID 
subscriber's directory number or line, depending upon the type of switch. Significantly, the 
call is not suspended at the switch during execution of the RACLID process. Rather, the call 
completes in a normal fashion. 

Detailed Description Text (42) : 

When the GDI server 92 receives the InvokeApp message from the ISCP 23, it first determines 
whether the subscriber has activated the RACLID service. This avoids unnecessary processing 
time in the event the RACLID service is OFF. The GDI server 92 accomplishes this by querying 
the Call Logger Database 95, which contains an ON/OFF indicator dedicated to the subscriber 1 s 
account. To activate the system, the subscriber accesses the Web server 43 by means of the Web 
client 30. The Web server 43 in turn accesses the Call Logger Database 95. The subscriber 
selects the ON option to activate the RACLID service, which then remains active until the 
subscriber accesses the Call Logger Database 95 and selects the OFF option. The subscriber may 
perform the ON/OFF commands through any means of access to the Web, as opposed to being limited 
to the phone number associated with the RACLID account. Note also that any conventional Caller 
ID system using customer premises equipment, such as a Caller ID box, by the same subscriber is 
unaffected by the ON/OFF command directed to the RACLID service. 

Detailed Description Text (43) : 

The servers and database communicate with one another using Java Database Conductivity ( JDBC) , 
although any appropriate interface may be used. Also, alternative embodiments of the invention 
combine the various server and database functions into any combination of systems, including a 
single server. With respect to subscriber access to the system, the communication between the 
Web server 43 and the Web client 30 uses HTTP, although any appropriate interface may be used. 

Detailed Description Text (44) : 

Once the GDI server 92 detects the active or ON status, it proceeds to contact the directory 
database server 93 to retrieve the calling party's name associated with the telephone number 
provided by the ISCP 23. In an embodiment, the directory database server 93 is a Line 
Information Database (LIDB) server. The LIDB server is maintained independently of the PSTN and 
updated appropriately by the service provider to assure provision of current information. The 
invention may include any comparable server, however, including a Lucent LDAP server. After the 
calling party name is retrieved from the LIDB, the GDI server 92 then provides the calling 
party's name, along with the caller data provided by the ISCP 23, including the calling party's 
number, the called number, the call date and the call time (collectively referred to as Caller 
ID information), to the Call Logger Database 95, where it is stored for later, retrieval. 

Detailed Description Text (45) : 

In an alternative embodiment (not pictured) , the ISCP 23 contacts the directory database server 
93 directly to retrieve the calling party's name associated with the calling party's telephone 
number. The ISCP 23 then sends the calling party's name to the GDI server 92, along with the 
calling party's number, the called number and the current date and time in the InvokeApp 
message. The GDI server 92 then provides this Caller ID information to the Call Logger Database 
95, where it is stored for later retrieval. Although obtaining the information from the 
directory database server 93 somewhat more efficiently, this embodiment requires additional 
work by the ISCP 23. 

Detailed Description Text (46) : 

In order to retrieve the Caller ID information from the Call Logger Database 95, the subscriber 
simply accesses the Web server 43 once again, through any means of access to the Web, and 
enters authentication data at the log-in. Assuming the subscriber is running the PCM, he or she 
then selects the RACLID option from the PCM Summary Web page 801 of FIG. 10, which is a block 
diagram of the various functions available to a typical user at the RACLID service Web page, 
discussed further below. 

Detailed Description Text (47) : 

Alternative embodiments of the invention do not require specific incorporation of the PCM. For 
example, one embodiment enables RACLID subscribers, including those who do not necessarily have 
PCM, to go directly to a RACLID dedicated home page, which would be substantially similar in 
appearance to that depicted in FIG. 7. 
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Detailed Description Text (48) : 

Next, the Web server 43 receives the log-in information from the Web client 30 and queries the 
directory server 93 to retrieve authentication data corresponding to the user account. The 
authentication data includes a user identification and a password. The user identification is 
any name, not necessarily unique within the RACLID system, determined by the subscriber . In one 
embodiment, the user identification and password correspond to the user identification and 
password of the PCM. The Web server 43 then requests input of the authentication data from the 
subscriber and compares the input data with the directory server data to determine a match. 

Detailed Description Text (49) : 

After authentication, the Web server 43 processes the commands entered by the subscriber . 
Available commands are depicted in FIG. 10 in the Call Log 802. One command sent automatically 
upon logging onto the RACLID service is the request data command, pursuant to which the Web 
server 43 retrieves all stored caller information from the Call Logger Database 95, including 
the calling party's name and. corresponding phone number and the date and time the call was 
placed. This information is displayed as indicated, for example, in FIG. 7. 

Detailed Description Text (50) : 

Another command is the delete data command '810, pursuant to which the Web server 43 removes the 
stored Caller ID information associated with a selected calling party from the Call Logger 
Database 95. If no delete command is executed by the subscriber, the Caller ID information 
stays in the Call Logger Database 95 and will continue to be retrieved pursuant to further 
request data commands until a delete command is sent or until some predetermined drop time 
expires, for example, 30 days. In one embodiment, the drop time may be adjusted by the 
subscriber . 

Detailed Description Text (51) : 

Other interactive commands, shown in FIG. 10, include the delete all command 806 and the 
refresh display command 805 for the subscriber ' s convenience. Pursuant to the delete all 
command, the Web server 43 erases from the Call Logger Database 95 the Caller ID information 
currently and displayed. Pursuant to the refresh display command, the Web server 43 queries the 
Call Logger Database 95 with an updated request data command, which would retrieve any caller 
information received after execution of the previous request data command. The ON/OFF switch 
803 is also provided on the display Web page to activate/deactivate the RACLID service. 

Detailed Description Text (52) : 

In the PCM environment, RACLID data may be used to accommodate other optional services. For 
example, the Directory Entry service 807 of FIG. 10, when selected by the user, automatically 
deposits name and telephone number information in the user's personal directory. In an 
alternate embodiment, the data may populate data in a PDA, e.g., a 3Com Palm Pilot. The Voice 
Over Internet 808 automatically places a call to the selected telephone number over the 
existing network connection. The user can also select the return to PCM Summary option 811 to 
access other services. 

Detailed Description Text (54) : 

In an embodiment of the invention, a user's interaction with the PCM, as well as the 
functionality of the PCM, is implemented with object-oriented programming, the terminology of 
which incorporates "classes" and "types." A class is a programming construct for defining the 
implementation of objects (e.g. users, telephone numbers, and services) that have the same sort 
of data and procedures. A type specifies the properties of a set of objects without reference 
to implementation. A type therefore can be implemented as many different classes. A type can 
also be implemented as a C++ class or as a JAVA class, and it can even be implemented in 
multiple ways within the same language. 

Detailed Description Text (59) : 

Administrative interaction with the PCM account uses PcmAccount 1202 operations, which include 
for example setName, setID, setSuperUser, addUser, removeUser, addPhoneNumber, 
removePhoneNumber, addService and removeService, which enable the account to be defined. 
Management of a PCM account includes creating the account. To do so, the subscriber must 
provide necessary personal information to the PCM service provider in exchange for the unique 
log-in ID and name. The webmaster initiates the account using the setName and setID operations, 
respectively. The ID is essentially the password and therefore must differ from every other PCM 
account ID known to the system. The name, however, need not be necessarily unique. 
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Detailed Description Text (60) : 

In its initial state, a PCM account is additionally assigned a superuser (usually the 
subscriber ) , a set of authorized users (initially consisting only of the account superuser), a 
personal directory for the superuser and a set of one or more associated phone numbers. The 
webmaster sets the initial PCM account superuser using the setSuperUser operation. The 
superuser must be a member of the account and, as stated above, has read and write privileges 
to the account. Either the webmaster or the account superuser can then add new users to the 
account if a new user is not already a member using the addUser operation. After an operation 
adding a user is complete, the PCM account and the new user will cross reference each other in 
the attributes of User 1102 and PcmAccount 1202, which information is stored in the ASI server 
42 in one embodiment. 

Detailed Description Text (61) : 

This operation does not provide the new user access to any of the account telephone numbers, 
which is performed separately under an AddPhoneNumber operation on a phone number by phone 
number basis. This data is likewise stored at the ASI server 42. Both the webmaster and the 
superuser provide access to the specified phone number within the PCM account. The telephone 
number and user must already belong to the account. 

Detailed Description Text (62) : 

The webmaster or the superuser can likewise remove a user from an account if the user is 
already a member of the account using the removeUser operation. The user to be removed cannot 
be the account's superuser. After the operation completes, the cross-references in the 
attributes of User 1102 and PcmAccount 1202 are eliminated and all telephone number access 
privileges are revoked. 

Detailed Description Text (63) : 

The webmaster can add a telephone number to a PCM account if that phone number is not already 
in the account. Again, after the operation completes, the account and the new phone number will 
have references to each other in the attributes of User 1102 and PcmAccount 1202 stored at the 
AIS Server 42. The added phone number will necessarily include the account's superuser in its 
list of allowed users. The webmaster can likewise remove a phone number from a PCM account if 
that phone number already belongs to the account using the removePhoneNumber operation. After 
the operation completes, neither the account nor the telephone number have references to each 
other in attributes of User 1102 and PcmAccount 1202. 

Detailed Description Text (64): 

The webmaster can perform other functions in the PCM account, as well. For example, the 
webmaster can add a service to a telephone number in an account if that service is not already 
present on that phone number. The webmaster can likewise remove a service from a phone number 
in an account. Also, the webmaster can add or remove a personal directory to the account. 

Detailed Description Text (73) : 

Although the present specification describes components and functions implemented in the 
embodiments with reference to particular standards and protocols, the invention is not limited 
to such standards and protocols. Each of the standards for Internet and other packet switched 
network transmission (e.g., TCP/IP, UDP/IP, HTML, SHTML, DHTML, XML, PPP, FTP, SMTP, MIME) ; 
peripheral control (IrDA; RS232C; USB; ISA; ExCA; PCMCIA), and public telephone networks (ISDN, 
ATM, xDSL) represent examples of the state of the art. Such standards are periodically 
superseded by faster or more efficient equivalents having essentially the same functions. 
Accordingly, replacement standards and protocols having the same functions are considered 
equivalents. 

CLAIMS : 

2. The method of claim 1, further comprising determining whether the subscriber has activated 
the remote caller ID service. 

5. The method of claim 4, wherein receiving the caller ID query further comprises receiving, at 
a Web server, the caller ID query from the subscriber via a Web client; and wherein 
transmitting the caller ID data to the remotely connected subscriber further comprises 
transmitting the caller ID data from the Web server to the web client. 
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6. w A method for implementing a remote access to caller ID service for a subscriber, the service 
providing caller ID information associated with a telephone call from a calling party to a 
destination of a subscriber, the caller ID information being provided over a plurality of 
networks to the subscriber at a location remote from the destination, the method comprising: 
obtaining, at a service control point, calling party information associated with the calling 
party from a switch, the calling party information comprising at least a telephone number 
associated with the calling party; transmitting from the service control point to a GDI server 
the calling party information, while the service control point continues to process the call; 
obtaining, at the GDI server, additional information associated with the calling party from a 
directory server, the additional information comprising at least a name associated with the 
telephone number of the calling party; transmitting the caller ID data, comprising the calling 
party information and the additional information, from the GDI server to a call logger 
database; receiving a caller ID query from the remotely located subscriber via at least one of 
the networks; retrieving the caller ID data from the call logger database in response to the 
caller ID query; transmitting the caller ID data to the remotely located subscriber via at 
least two of the networks; and providing the caller ID information at the remote subscriber 1 s 
location . 

10. A system for implementing a remote access to caller ID service for a subscriber, the 
service providing caller ID information associated with a telephone call from a calling party 
to a destination of a subscriber, the caller ID information being provided over a plurality of 
networks to the subscriber at a location remote from the destination, the system comprising: a 
service control point that receives calling party data from a switch, associated with the 
subscriber destination, in response to the telephone call, the calling party data comprising at 
least a telephone number associated with the calling party; a GDI server that receives the 
calling party data from the service control point, while the service control point continues to 
process the call, the GDI server obtaining additional data associated with the calling party 
from a directory server, the additional data comprising at least a name associated with the 
telephone number of the calling party; a call logger database that receives the caller ID 
information from the GDI server, the caller ID information comprising the calling party data 
and the additional data; a network server configured to receive a first caller ID query from a 
client over a first network and, in response to the caller ID query, retrieves the caller ID 
information from the call logger database and forwards the caller ID data to the client; and an 
interactive voice response (IVR) configured to receive a second caller ID query from a 
telephone over a second network and, in response to the second caller ID query, retrieves the 
caller ID information from the call logger database and forwards the caller ID information to 
the telephone ; wherein the subscriber can obtain the caller ID information from the server and 
the IVR while being located remotely from the destination of the telephone call associated with 
the caller ID data. 

12. The system for implementing the remote access to caller ID service according to claim 11, 
wherein the second network comprises a public switched telephone network. 
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